Управление уязвимостями и Vulnerability Management: как выстроить процесс и выбрать VM-платформу

...

Управление уязвимостями: как выстроить процесс Vulnerability Management в компании

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

1. Введение
2. Часть I. Эволюция управления уязвимостями
3. Часть II. Практика управления уязвимостями
4. Выводы

Введение

Управление уязвимостями (Vulnerability Management, VM) давно перестало быть разовой акцией или формальной обязанностью ИБ-отдела. В современном ландшафте киберугроз, где количество ежедневно публикуемых CVE исчисляется сотнями, а сложность ИТ-инфраструктуры растёт экспоненциально, VM превратилось в один из ключевых процессов обеспечения киберустойчивости компании.

Однако на практике путь от «просто установить сканер» до выстроенной, измеримой и работающей системы управления уязвимостями оказывается тернистым. Организации сталкиваются с типичными проблемами: как отсеять ложные срабатывания, где взять компетенции для проверки критичности уязвимости, как наладить взаимодействие с ИТ-подразделениями, которые отвечают за патчи, и главное — как превратить бесконечный поток уязвимостей в управляемый процесс с понятными сроками и метриками.

Вопросы приоритизации, автоматизации, интеграции со смежными системами (SIEM, SOAR, Service Desk) и внедрения элементов искусственного интеллекта сегодня выходят на первый план. При этом рынок предлагает разные пути: от использования классических сканеров до комплексных VM-платформ, которые закрывают полный цикл — от обнаружения до подтверждения устранения.

Часть I. Эволюция управления уязвимостями

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

Рисунок 1. Участники первой части эфира

Участники:

Павел Попов, руководитель группы инфраструктурной безопасности, Positive Technologies.
Дмитрий Черняков, директор по развитию продуктов, RedCheck.
Александр Дорофеев, генеральный директор, «Эшелон Технологии».
Данила Луцив, руководитель продуктового направления Vulnerability Management, Security Vision.
Мария Погребняк, старший менеджер по развитию бизнеса, «Лаборатория Касперского».
Андрей Никонов, заместитель директора, «Смартап» (Vulns.io VM).
Роман Долгий, руководитель направления специальных сервисов Solar JSOC, ГК «Солар».

Ведущий и модератор эфира — Кирилл Мякишев, CISO, Ozon.

Проверка и приоритизация уязвимостей

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

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

Дмитрий Черняков, директор по развитию продуктов, RedCheck

Александр Дорофеев рассказал о трёх подходах. Первый: на каждую уязвимость пишется скрипт. Второй: на каждую уязвимость создаётся XML-описание, и нужен агент, который прочитает его и проверит, соблюдены ли условия. Третий: база уязвимостей, формируемая из NIST NVD, БДУ ФСТЭК России, вендорских баз (отечественных или западных).

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

В первом опросе зрители ответили, как в их компании выстроен процесс управления уязвимостями (мультивыбор):

Проводят регулярное сканирование — 83 %.
Проводят приоритизацию уязвимостей — 72 %.
Формализован процесс и роли сотрудников — 57 %.
Контролируют время закрытия уязвимостей — 38 %.
Моделируют эксплуатацию и оценивают возможный ущерб — 12 %.

Рисунок 2. Как в вашей компании выстроен процесс управления уязвимостями?

Как проводить скоринг уязвимостей?

Роман Долгий уверен, что нужно использовать все доступные средства. Регуляторы рекомендуют опираться на CVSS, но этот стандарт содержит в себе далеко не всё. Следует смотреть, эксплуатируется ли данная уязвимость и эксплуатируется ли она вообще — то есть её трендовость. Где брать информацию? Многие вендоры подсвечивают в своём интерфейсе, что уязвимость трендовая. Также можно обращаться к экспертным сообществам, блогам вендоров и интеграторов, поставщикам сервисов.

Андрей Никонов рекомендует методику ФСТЭК по оценке критичности уязвимостей. Она берёт за основу CVSS как сложившийся годами стандарт. При большом желании и ресурсах можно изменить этот вектор, но тем не менее за базовую оценку опасности принимается CVSS, после чего она накладывается на призму конкретной инфраструктуры.

Если компания действительно зрелая, а её ИБ-процессы согласованы внутри, можно распределить критичность активов. Если нет — методика ФСТЭК России всё равно даёт формальные базовые коэффициенты. Это основа, с которой уже можно работать. Приоритизация по ФСТЭК хороша тем, что мы опираемся не на абстрактный CVSS, а профилируем оценку под нашу индивидуальную инфраструктуру и конкретный актив. Важно при этом правильно пересчитывать метрики.

Андрей Никонов, заместитель директора, «Смартап» (Vulns.io VM)

Блиц: важные метрики процесса Vulnerability Management

Роман Долгий: «Потенциальный простой для бизнес-критичных систем из-за неустранённых уязвимостей».

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

Мария Погребняк: «Уменьшение количества уязвимостей в дифференциальном отчёте».

Данила Луцив: «Среднее время устранения критической уязвимости за последние 3 или 6 месяцев в разрезе по ИТ-командам».

Александр Дорофеев: «Процент активов от общего количества активов, которые находятся под контролем в процессе VM».

Дмитрий Черняков: «Выбранное средство должно соответствовать покрытию инфраструктуры, важно учитывать точность детектирования и наличие дополнительных сведений по каждой уязвимости».

Павел Попов: «Количество устранённых уязвимостей должно расти, а на периметре не должно быть высоких и критических уязвимостей. Самый высокий уровень зрелости — это гарантия, что компанию не взломают через уязвимости».

Павел Попов, руководитель группы инфраструктурной безопасности, Positive Technologies

Как построить систему управления уязвимостями без VM-платформы?

Александр Дорофеев считает, что построить систему управления уязвимостями без VM-платформы можно, используя качественный сканер с открытым API. Это позволит настроить интеграции с системами тикетинга, управления активами и уведомлениями, чтобы вручную не переносить данные. По сути, вы сами собираете решение из сканера и связок через API.

Роман Долгий уверен, что такой процесс построить реально, но он отнимет много времени и денег. Выбор простой: либо вы платите за готовую VM-платформу с автоматизацией, либо тратите ресурсы ИТ и ИБ на ручную аналитику выгрузок из сканера и перенос данных в смежные системы. Автоматизация стоит денег, ручной труд — времени ваших команд.

Роман Долгий, руководитель направления специальных сервисов Solar JSOC, ГК «Солар»

Во втором опросе выяснилось, как зрители проводят приоритизацию обнаруженных уязвимостей (мультивыбор):

По CVSS — 53 %.
По типу уязвимого актива и его критичности — 46 %.
Проводят скоринг по всем перечисленным параметрам — 32 %.
По факту наличия эксплойта — 28 %.
Смотрят на трендовость уязвимости — 23 %.
Никак не проводят — 7 %.

Рисунок 3. Как вы проводите приоритизацию обнаруженных уязвимостей?

На какие критерии ориентироваться при выборе VM-систем?

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

Дмитрий Черняков: «Важна функциональность для перехода к процессам управления экспозициями — комплаенс, инвентаризация, контроль целостности. Сканер должен быть нацелен не только на уязвимости, но и на другие аспекты сканирования».

Александр Дорофеев: «Смотрите, в каких средах работает сканер: обязательна поддержка отечественных операционных систем и Windows. Стоимость — немаловажный фактор. Также важен анализ конфигурации: мы из коробки даём порядка 50 шаблонов для СЗИ и ОС. И, конечно, необходима возможность интеграции».

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

Данила Луцив, руководитель продуктового направления Vulnerability Management, Security Vision

Мария Погребняк: «Мы двигаемся от простого к сложному, специфика отталкивается от инфраструктуры других решений. Наш вероятный заказчик — тот, кто уже использует агента. Наша задача — дать таким людям возможность усилить уже используемого агента функциями VM».

Андрей Никонов: «При выборе нужно помнить, что мы хотим закрыть процесс управления уязвимостями, а это не только сканер и отчётность, но и устранение. Система должна максимально автоматизировать процессы. В остальном выбор зависит исключительно от того, что нужно конкретной организации».

Роман Долгий: «Главное — это применимость в инфраструктуре конкретного заказчика и простота использования».

В третьем опросе зрители назвали главные препятствия для полноценного управления уязвимостями в их организациях:

ИТ не успевает или не хочет закрывать уязвимости — 32 %.
Сложно выстроить рабочий процесс — 23 %.
Нет нормальной инвентаризации активов — 19 %.
Нет денег на покупку VM-платформы — 16 %.
Сложно приоритизировать уязвимости — 7 %.
Нет квалификации и опыта — 3 %.

Рисунок 4. Что является главным препятствием для полноценного управления уязвимостями?

Автоматизация и внедрении ИИ

Роман Долгий считает, что автопатчингу доверять можно, но ограниченно — на неключевых сегментах сети, и нужно перепроверять. Подключать ИИ можно на том этапе, когда уже исчерпаны возможности человеческого интеллекта. Слепо доверяться ему нельзя. Его можно использовать тогда, когда мы понимаем, для чего он нужен.

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

Мария Погребняк рассказала, что использовать ИИ нужно тогда, когда на это есть деньги. Хороший ИИ, который действительно поможет значительно усилить процесс на этапе Exposure Management, когда строится путь атаки, требует колоссальных ресурсов.

Мария Погребняк, старший менеджер по развитию бизнеса, «Лаборатория Касперского»

Данила Луцив считает, что автопатчинг — это прерогатива ИТ-специалистов, и ИБ должна подстраиваться под них. Необходимо встраиваться в существующие ИТ-процессы и следить за их исполнением. ИИ в большинстве продуктов уже есть — переводчики, категоризаторы. Сейчас невозможно анализировать тот поток уязвимостей, который существует, без использования ИИ.

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

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

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

Александр Дорофеев, генеральный директор, «Эшелон Технологии»

В четвёртом опросе зрители поделились, планируют ли они внедрять или усиливать процесс VM после эфира:

Будут усиливать процесс VM — 67 %.
Сомневаются, считают это избыточным — 17 %.
Планируют внедрить платформу VM в 2026 году — 8 %.
Ничего не поняли, о чём говорили эксперты — 8 %.
Пока не видят практической пользы — 0 %.

Рисунок 5. Планируете ли вы внедрять или усиливать процесс VM после эфира?

Кирилл Мякишев резюмировал первую часть эфира. Он уверен, что управление уязвимостями (Vulnerability Management, VM) было и остаётся важной составляющей и базовым процессом обеспечения безопасности. В работе ИБ-специалиста многое зависит от смежных подразделений и от того, насколько правильно он коммуницирует с ними.

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

Кирилл Мякишев, CISO, Ozon

Часть II. Практика управления уязвимостями

Главные вопросы второй части: что на самом деле тормозит внедрение Vulnerability Management? Как выстроить интеграции, чтобы они не парализовали работу ИТ? Можно ли заставить закрывать уязвимости, если регламенты не работают? И как часто нужно сканировать инфраструктуру, чтобы не утонуть в ложных срабатываниях, но и не пропустить реальную угрозу? В этой части — ключевые инсайты о зрелости компаний, KPI для ИТ и ИБ, подводных камнях после внедрения VM и практических шагах для старта.

Рисунок 6. Участники второй части эфира

Участники:

Даниил Белицкий, ведущий архитектор SOC, SolidLab.
Кирилл Селезнёв, product owner ETM / VM, CICADA8.
Владимир Еронин, директор по развитию бизнеса, «Крайон».
Максим Лызаев, менеджер по сопровождению корпоративных продаж, «Лаборатория Касперского».
Дмитрий Кузьмин, директор, блок «Цифровая крепость ВЭБа», ВЭБ.РФ.
Давид Ордян, генеральный директор, Metascan.

Ведущий и модератор эфира — Лев Палей, директор по информационной безопасности, WMX.

Что тормозит внедрение VM?

Даниил Белицкий считает, что нужно понимание со стороны заказчика, для чего вообще нужно управление уязвимостями (Vulnerability Management, VM). Многие не знают, что это им даст и какие преимущества они получат. Ещё одна возможная причина — непонимание собственной инфраструктуры.

Владимир Еронин рассказал, что частым заблуждением является вера в то, что одного сканера уязвимостей достаточно для выстраивания процесса управления уязвимостями (VM), но на самом деле это не так. Инструмент — это хорошо, а вот наличие выстроенного процесса внутри компании — совсем другой вопрос.

Кирилл Селезнёв считает, что важна зрелость компании. У заказчиков должны быть ресурсы — время, деньги и люди.

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

Давид Ордян добавил, что важно понимание ценности информационной безопасности со стороны бизнеса. Как вендоры сканеров, они должны донести эту ценность на старте и обосновать её бизнесу.

Давид Ордян, генеральный директор, Metascan

Интеграция VM-платформ

Даниил Белицкий считает, что если есть выстроенный зрелый процесс SOC, то обязательно нужна интеграция с SIEM и SOAR для построения корреляционных правил и быстрой передачи данных, а также интеграция с тикет-системами.

Кирилл Селезнёв рассказал, что у них на практике большинство запросов идёт в сторону ITSM, CMDB, Service Desk и SIEM. Заказчикам необходим контроль активов, ответственных лиц и инцидентов, которые могут возникать.

Владимир Еронин отметил, что бывают перегибы, когда интеграция с Service Desk происходит в автоматическом режиме и туда выгружается решительно всё. Это делает невозможной дальнейшую работу для подразделений, которые устраняют уязвимости. Но при этом без интеграции с Service Desk тоже плохо: если её нет и приходится выгружать данные вручную, появляется зависимость от конкретного специалиста, что повышает риски для компании.

Владимир Еронин, директор по развитию бизнеса, «Крайон»

Давид Ордян рассказал, к чему они идут и чего можно хотеть от вендора в 2026 году. Сейчас они предоставляют MCP — интерфейс для взаимодействия с LLM и AI-агентами. Если в компании развивается ИИ-направление, можно сделать сканер частью AI-обвязки для поиска уязвимостей на внешнем и внутреннем периметре. Если посмотреть на западных производителей, сейчас идёт интеграция с движками SGRC — для расчёта киберущерба, финансовых потерь и стоимости решения.

В первом опросе зрители назвали главную проблему в процессе управления уязвимостями в своей организации:

Закрытие уязвимостей — 37 %.
Инвентаризация активов — 23 %.
Регулярное сканирование — 12 %.
Контроль устранения уязвимостей — 12 %.
Приоритизация уязвимостей — 7 %.
Другое — 6 %.
Затруднились ответить — 3 %.

Рисунок 7. Какова главная проблема в процессе управления уязвимостями в вашей организации?

Как часто нужно сканировать инфраструктуру?

Дмитрий Кузьмин рассказал, что, когда он начинал строить процесс, он взял цифры из американских стандартов CISA по уязвимостям — в них в конце есть достаточно большая таблица о том, когда и как часто нужно сканировать в зависимости от критичности группы активов. Плюс они организуют проверку раз в 3 месяца: выделяют 1 день, в течение которого всё, что не прошло через экстренные исправления, далее проверяется.

Максим Лызаев отметил, что частично скан может быть таким, что он не нагружает сеть, — например, агентским. Агент собирает инвентаризацию, отправляет её на сервер, а анализ запускается на сервере в нужное время. При этом агент постоянно мониторит состояние, и если что-то изменилось — досылает данные.

Максим Лызаев, менеджер по сопровождению корпоративных продаж, «Лаборатория Касперского»

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

Давид Ордян считает, что в идеале систему нужно перепроверять всегда, когда её состояние изменилось. При любом изменении необходимо проводить проверку. Если состояние не менялось, сканировать не нужно, за исключением случаев, когда вышла новая уязвимость.

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

Даниил Белицкий, ведущий архитектор SOC, SolidLab

Как заставить закрывать уязвимости?

Владимир Еронин считает, что нужно выстроить процессы: дать удобные инструменты и всю необходимую информацию о том, что нужно сделать для закрытия уязвимостей. Должны быть SLA, которые будут соблюдаться. Это должно попасть в метрики, которые станут показателями эффективности для соответствующих сотрудников. В первую очередь здесь важны именно процессы управления уязвимостями.

Кирилл Селезнёв рассказал, что самый эффективный способ в их практике — это KPI. В KPI команд ИТ и ИБ закладывают конкретные метрики по SLA, срокам жизни уязвимостей и контролю уязвимостей на периметре. Других вариантов, которые успешно отработали на их практике, просто нет.

Во втором опросе зрители ответили, какие инструменты VM уже используются в их организации:

Только сканер — 37 %.
VM-платформа — 28 %.
VM-платформа с автоматизацией — 23 %.
Ничего не используется — 8 %.
Сканер и трекер задач — 4 %.

Рисунок 8. Какие инструменты VM уже используются в вашей организации?

Проблемы после внедрения решений VM

Даниил Белицкий считает, что, как правило, не хватает ресурсов на патчинг или у заказчика не организован процесс. Есть много причин, по которым заказчик начинает откладывать устранение уязвимостей в долгий ящик.

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

С другой стороны, командам заказчика бывает тяжело эту информацию перерабатывать и действовать по ней. Нужно найти баланс. Нет виноватых — надо объединиться и делать процесс с обеих сторон максимально эффективным. Также важно смотреть на боли заказчика и донастраивать продукт так, чтобы специалистам ИТ и ИБ было комфортно с ним работать.

Кирилл Селезнёв, product owner ETM / VM, CICADA8

Давид Ордян рассказал, что проблема часто кроется в самом процессе. У заказчика есть инструмент (VM-платформа, причём разная), есть регламенты, KPI и метрики, соблюдается периодичность — но всё равно что-то идёт не так. И здесь важнее всего разговаривать с людьми. По результатам становится ясно, что примерно 60 % всех проблем упираются не в отсутствие ресурсов и не в нежелание брать на себя ответственность.

В большинстве случаев проблема чисто техническая: просто непонятно, как работает та или иная уязвимость, в чём именно заключается угроза и можно ли с её помощью реально нанести ущерб. Как только начинаешь вовлекать в ИБ-процесс смежные подразделения — сетевиков, прикладных разработчиков, AppSec — проблема быстро решается. Главное — регулярно собираться вместе и обсуждать. В процессе живого обсуждения достаточно кому-то что-то объяснить, дать контекст, и процесс идёт гораздо быстрее.

В третьем опросе выяснилось, установлены ли в организациях респондентов сроки устранения уязвимостей:

Никакие сроки не установлены — 36 %.
Установлены, но чаще всего не соблюдаются — 32 %.
Установлены только для отдельных уязвимостей — 17 %.
Затруднились ответить — 8 %.
Установлены и соблюдаются — 7 %.

Рисунок 9. Установлены ли в вашей организации сроки устранения уязвимостей?

Ключевые тренды на ближайшие несколько лет

Дмитрий Кузьмин рассказал, что Gartner разработал новую концепцию Continuous Threat Exposure Management (CTEM). Это новая парадигма, которая меняет понимание уязвимостей. В первую очередь речь идёт о разделении на стратегические и тактические уязвимости.

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

Дмитрий Кузьмин, директор, блок «Цифровая крепость ВЭБа», ВЭБ.РФ

Кирилл Селезнёв считает, что интересные моменты на стыке разных продуктов могут возникнуть как развитие VM — например, VM с WAF, VM с NGFW и другими системами СЗИ. Внедрение ИИ должно приносить эффективность и снижать стоимость самих продуктов.

Давид Ордян выделил несколько тенденций. Первая — укрупнение решений: разделение на внешний и внутренний периметр становится уже не таким актуальным. Все приходят к модели, где мы защищаем внешний и внутренний периметры из одного интерфейса, но немного разными способами — агентские сканы, внутренние VM, интеграция между элементами сети.

Вторая — плотная интеграция с другими системами, такими как GRC и TI. Третья — LLM, генеративный контент, словари, подборы. Растёт зрелость VM: появился триаж, меняется сам процесс, подход, парадигма того, что мы хотим от вендора. Это во многом связано с ответственностью вендоров перед заказчиками.

Практические шаги при начале внедрения VM

Даниил Белицкий: «Приходите к тем VM-решениям, которые занимаются триажем и валидацией, берут на себя ответственность и не боятся, что вас завалят кучей ненужных тикетов и информации, перегружающей систему. Выбирайте зрелые VM-платформы, которые помогают разобраться, а не оставляют вас один на один с системой».

Кирилл Селезнёв: «Попробуйте нарисовать процесс управления уязвимостями так, как вы видите его в своей инфраструктуре: какие этапы и интеграции в нём предусмотрены, какие ожидания вы закладываете в основу. После этого переходите к выбору вендора и анализу конкретных кейсов, которые у него есть».

Владимир Еронин: «Управление уязвимостями — это непрерывный процесс, а не разовый проект. Важно, чтобы в его разработке участвовали все стороны и был налажен диалог».

Максим Лызаев: «Знайте свою инфраструктуру, понимайте, какие активы для вас наиболее ценны. Инвестируйте в процессы и в людей».

Дмитрий Кузьмин: «Выстраивайте отношения с ИТ и бизнесом через совместные задачи и мероприятия. Инвестируйте в человеческий капитал — это главное».

Давид Ордян: «До выбора вендора и запуска проекта идите к топ-менеджменту и договаривайтесь о том, что нужно бизнесу: какие системы критические, где ущерб от простоя будет максимальным. Получите от бизнеса инструменты для обеспечения процесса. Следующий шаг — метрики. Определите критические метрики по каждому субпроцессу: инвентаризация, управление сетевыми связями, управление уязвимостями, управление угрозами».

Лев Палей подытожил, что для успешного управления уязвимостями нужны все составляющие: выстроенные процессы, налаженные отношения между ИТ и ИБ, понимание своей инфраструктуры и чёткие метрики. Эти метрики (KPI) должны быть привязаны к тем сотрудникам, которые непосредственно закрывают уязвимости. Также стоит привлекать вендоров, которые готовы брать на себя часть работы и автоматизировать её. И самое главное — во всё это: в процессы, в людей, в отношения и в инструменты — нужно инвестировать.

Лев Палей, директор по информационной безопасности, WMX

Финальный опрос показал, каково мнение зрителей об управлении уязвимостями после эфира:

Убедились, что всё делают правильно — 42 %.
Будут следовать советам экспертов — 26 %.
Будут выстраивать процессы и внедрять VM-платформу — 17 %.
Считают интересным, но пока избыточным для себя — 12 %.
Участники не смогли заинтересовать — 3 %.

Рисунок 10. Каково ваше мнение об управлении уязвимостями после эфира?

Выводы

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

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

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

Практика показывает, что большинство проблем упирается в банальные, но от того не менее острые вопросы: отсутствие нормальной инвентаризации активов, размытые сроки устранения (или полное их отсутствие), нежелание ИТ-команд брать на себя обязательства по патчингу. И если с первыми 2 проблемами ещё можно справиться за счёт регламентов и KPI, то последняя требует системной культурной трансформации, где метрики по уязвимостям становятся частью оценки эффективности не только ИБ, но и ИТ.

В конечном счёте успех в управлении уязвимостями измеряется не количеством закрытых тикетов и не низким процентом ложных срабатываний. Он измеряется простым, но самым честным показателем: компанию не взломали через ту уязвимость, которую можно было закрыть. И этот результат достигается не одним вендорским решением, а ежедневной, часто рутинной, но выстроенной работой всех участников процесса — от аналитика ИБ до системного администратора и от руководителя ИТ до директора по информационной безопасности.

Телепроект AM Live еженедельно приглашает экспертов отрасли в студию, чтобы обсудить актуальные темы российского рынка ИБ и ИТ. Будьте в курсе трендов и важных событий. Для этого подпишитесь на наш YouTube-канал. До новых встреч!

Полезные ссылки:

Обзор решений для управления безопасностью и защиты МСБ

Как управлять уязвимостями в постоянно меняющейся ИТ-инфраструктуре

Обзор рынка систем управления уязвимостями (Vulnerability Management, VM)