Архив метки: VMprocess

Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1

Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1
Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1

Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1. На лайв-демо коллеги из R-Vision показали следующие кейсы (см. скриншоты):

🔻 Провели inventory-скан (показали новую карточку скана с фильтрами ошибок), определили хосты Cisco, создали и запустили простое правило для перемещения хостов в группу по типу ОС. В итоге наполнили группу "Сетевое оборудование Cisco".

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

🔻 Добавили уязвимость Cisco, которой не было в базе, через обновление и определили её ретроспективным аудитом на хостах. Проговорили, что в случае детектирования трендовой уязвимости можно автоматически отправлять алерт админу. 🚨

Также они поделились достижениями, статистикой, роадмапом и анонсом мероприятий.

Основное достижение - это перевод R-Vision на новую платформу EVO (до версии 5.4 были на платформе RVN).

R-Vision VM в цифрах (2025-2026):

🔹 +15 новых проектов (есть заказчики с 30k+ активов)
🔹 +50 пилотных проектов у клиентов
🔹 +25 пилотных проектов у партнёров
🔹 +55 обученных технических специалистов
🔹 +133 трендовые уязвимости в базе (дайджесты доступны на сайте R-Vision)
🔹 +180 поддерживаемых продуктов в режиме Audit
🔹 +88 поддерживаемых продуктов в режиме Pentest
🔹 +70 новых стандартов для режима Compliance

Роадмап ("R-Vision VM завтра"):

🔹 Поддержка аудита контейнерных сред
🔹 Поддержка аудита веб-приложений
🔹 Расширение аудита гипервизоров (ESXi, vCenter, …)
🔹 Расширение аудита сетевого оборудования (Qtech, S-Terra, Eltex, VipNET, UserGate, MikroTik, …)
🔹 Мастер первичной настройки
🔹 Сертификат ФСТЭК России (на VM EVO)
🔹 + Секретная функциональность ❗️ (анонс на R-Evolution Conference 2026)

Сам я на R-Evolution Conference, к сожалению, в этом году не попадаю. 😔 Но рекомендую сходить, был там несколько раз, мероприятие душевное.

На R-Evolution Conference будет несколько VM-ных докладов:

🔹 12:55 - 13:15 Смена двигателя на лету: год большой перестройки VM и куда дальше? (Бизнес-трек)
🔹 14:00 - 14:20 Опыт ТМХ: как выстроить управляемый VM на десятках тысяч активов (Бизнес-трек)
🔹 15:20 - 15:40 Где ломается VM: подводные камни инвентаризации в инфраструктуре на 18К+ активов, ЗАО ПАТИО (Технотрек - новинка, в прошлом году технотрека не было 👍)

Плюс обещают демозону с R-Vision VM, работающую весь день. 🔥

В Q&A секции понравились вопросы:

🔹 Какая функциональность будет востребована в системах VM в ближайшие 2-3 года?
"Управление экспозициями" (прямо так и сказали, было приятно услышать именно такую формулировку 😇), пути атаки, ИИ, возможность переваривать большую инфраструктуру, автоматизация.

🔹 Можно ли сейчас использовать решения R-Vision для построения путей атаки?
Сказали, что тема хорошая, но задача сложная, особенно для большой инфраструктуры. Пока они не говорят, что могут это делать, но тренд им нравится.

🔹 Сколько человек, занимающихся VM-ом, требуется для организации с 10k активов?
Ответили, что 10000 активов → минимум 10 человек в IT, минимум 5-7 человек в ИБ. В ИБ люди будут шарить роли. Как минимум нужен один человек, который будет часть времени выделять на VM-ные задачи. Автоматизировать всё можно, но кто-то должен отслеживать сбои.

В этот четверг, 26 марта, я собираюсь выступить на московской конференции Security Summit "Стратегия и тактика информационной безопасности"

В этот четверг, 26 марта, я собираюсь выступить на московской конференции Security Summit Стратегия и тактика информационной безопасности

В этот четверг, 26 марта, я собираюсь выступить на московской конференции Security Summit "Стратегия и тактика информационной безопасности". У меня там будет короткий доклад про эволюцию Vulnerability Management-а в Exposure Management. Буду рассказывать про то, как мы все жили не тужили где-то с начала нулевых: детектировали и приоритизированно устраняли уязвимости и мисконфигурации, называя это "Управление Уязвимостями". А потом бац - в 2017 году маркетологи Tenable придумали для позиционирования своих решений на рынке использовать вместо уязвимостей слово "exposures" - максимально обтекаемое и неконкретное даже на английском, а тем более при попытках перевести его на русский. И эти самые "exposures" настолько зашли консалтерам из Gartner, что где-то с 2022 года они стали использовать их в хвост и гриву в рамках своей концепции "продвинутого VM-а" под аббревиатурой CTEM (Continuous Threat Exposure Management). И т.к. Gartner в деле ИБ-шного маркетинга могущественны и влиятельны, то сейчас на Западе VM практически закончился. 🤷‍♂️ У всех бывших VM-вендоров сплошной CTEM через CTEM, естественно определяемый так, как конкретному вендору выгодно. 😏 И, соответственно, масса сопутствующей маркетинговой активности: новые продуктовые ниши для решений (EAP, AEV, VPT, EASA, CAASM, APM, APA, BAS, Auto PT, CART, APS, TIP, DRPS, ASCA, X-SPM - можно подумать, что я рандомно стучу по клавиатуре, но нет 😅), новые квадранты, масса аналитики на тему (полезной и не очень). Работают люди! 😉

И тут, глядя на это западное маркетингово-консалтинговое пиршество духа из подсанкционной России, возникает вопрос: игнорировать его или интерпретировать (желательно не сильно противореча оригиналу) и попытаться извлечь некоторую практическую пользу (чтобы EM не выхолостился просто в модный синоним VM-а). Учитывая, что мы чай не в лесу живём, игнорировать не выглядит хорошим вариантом - всё это так или иначе сюда придёт и будет использоваться. Получается, следует включаться в это использование, чётко определяя, что такое exposures (экспозиции, "уязвимости в широком смысле"), что такое Exposure Management ("управление экспозициями"), что такое CTEM ("непрерывное управление экспозициями с учётом угроз") и какая функциональность для этих классов решений является ключевой и приносящей реальную пользу.

В общем, примерно таким будет выступление. Заглядывайте на мероприятие, пообщаемся. 🙂 Positive Technologies - генеральный партнёр, поэтому на стенде про PT-шный взгляд на CTEM тоже расскажем и покажем продукты, которые его реализуют. 😉

Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1

Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1
Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1

Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1. Резюме маркетологов R-Vision: "в релизе особое внимание было уделено тому, что важно в ежедневной работе: ускорении поиска уязвимостей, гибкой приоритизации и автоматизации рутинных процессов".

Подробности и демо, видимо, стоит ожидать на вебинаре 24 марта и на конференции R‑EVOlution 9 апреля.

В пресс-релизе R-Vision сделали акцент на следующие фичи:

🎯 Поиск уязвимостей без повторного сканирования "Ретроспективный аудит". Представляется как ключевое нововведение версии. Механизм позволяет выявлять уязвимости на основе ранее собранных данных, без запуска повторного сканирования. Фича опциональная. Можно настроить для отдельных хостов, групп хостов или для всех хостов. Запускается по триггерам - обновление базы (сразу пересчитывается по всем указанным целям), по расписанию или вручную.

С технической точки зрения здесь речь идёт о повторной корреляции уже собранных атрибутов активов (например, CPE, версии ПО, установленные пакеты, баннеры сервисов, результаты аутентифицированных проверок, конфигурационные артефакты) с обновлённой базой уязвимостей (в случае R-Vision речь, видимо, идёт о правилах детектирования уязвимостей на OVAL-like языке). За счёт того, что сбор актуальных данных о хосте не производится, новые уязвимости могут быть выявлены практически мгновенно, без нагрузки на сеть и хосты.

Ограничение такого подхода в том, что он строго зависит от полноты и качества ранее собранных данных. Если, например, при последнем сканировании по каким-то причинам не была получена точная версия ПО, то корректный match с новой уязвимостью для этого ПО не получится. Аналогично, любые изменения после последнего скана (установка нового ПО, появление сервиса, изменение конфигурации) не будут учтены. Поэтому ретроспективный аудит — это слой аналитики поверх исторических данных, и он должен работать в связке с регулярным агентным/безагентным сканированием для актуализации данных об активах.

🧠 Графический конструктор расчёта рейтинга уязвимостей. Фича позволяет настраивать формулу приоритизации уязвимостей прямо в интерфейсе, используя атрибуты уязвимости, оборудования или групп ИТ-активов. Формула может учитывать различные типы данных (числовые, текстовые и справочники), что позволяет гибко адаптировать расчёт рейтинга под особенности конкретной ИТ-инфраструктуры.

Пример формулы для расчёта рейтинга уязвимости:

round((mean({calculation:calculate_cvss}) * (mean({calculation:calculate_k}) + mean({calculation:calculate_l}) + mean({calculation:calculate_p})) *
(mean({calculation:calculate_lat}) + mean({calculation:calculate_limp}))) * 10) / 10

Доступны преднастроенные варианты, включая основанный на Методике оценки уровня критичности уязвимостей (ФСТЭК 30.06.2025).

С технической точки зрения это реализация движка кастомного скоринга, где итоговый рейтинг вычисляется через пользовательское выражение, а UI выступает как визуальный конструктор над ним. В формуле используются атрибуты из разных источников (уязвимость, актив, контекст), а пересчёт выполняется автоматически при изменении данных. Это позволяет уйти от статичного CVSS к контекстной приоритизации уязвимости. Однако следует учитывать, что сложность таких моделей быстро растёт, их трудно валидировать и поддерживать, а итоговое качество напрямую зависит от полноты и актуальности данных об активах и уязвимостях.

⚙️ Новый механизм политик управления активами и уязвимостями. Он позволяет задавать правила, которые автоматически срабатывают при наступлении заданных условий (по событию или по расписанию). Заявляется, что политики могут изменять атрибуты любых объектов системы или выполнять нужные действия: например, создавать задачу на устранение уязвимости при ее появлении, менять статус актива при обновлении данных или автоматически переводить уязвимость в нужную категорию на основании ее параметров. Поддерживается работа со всеми полями объектов. Это позволяет реализовывать сложные пользовательские сценарии – как в части управления уязвимостями, так и при построении ресурсно-сервисных моделей активов.

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

📂 Сканирование групп IT‑активов. Теперь группы IT‑активов можно использовать в задачи сканирования (как в списке целей, так и в исключениях). Состав таких групп может автоматически изменяться, что позволяет использовать одну задачу для актуальных групп активов и упрощает организацию процесса сканирования. Пример групп активов со скриншота: "Критичные устройства", "Критический ГИТ". Сканирование выполняется по IP или FQDN хоста.

Ценность - снижение операционных затрат и уменьшение ошибок. Ограничения - зависимость от корректности группировки: при ошибках в логике формирования групп возможны пропуски или избыточное сканирование, а также меньшая предсказуемость состава целей в конкретный момент времени.

📊 Улучшение информативности карточки задачи сканирования. Туда добавили статистику выполнения, отображение прогресса и ошибок подключения или сбора данных, что упрощает диагностику и контроль хода сканирования.

На последнем скриншоте можем видеть историю запусков. Для запуска показывается статус (завершён/отменён), статистику выполнения сканирования по целям, четырёхсегментный индикатор для статуса сканирования каждого таргета. Довольно симпатично. 🙂

⏱️ Настройка работы агентного сканирования. Появилось настраиваемое расписание, позволяющее задавать периодичность и время сбора данных.

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

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

В целом, по описанию все фичи выглядят интересно. Ждём демо. 🙂

На сайте ФСТЭК 10 марта был опубликован документ с рекомендациями по защите сетевого периметра информационных (автоматизированных) систем

На сайте ФСТЭК 10 марта был опубликован документ с рекомендациями по защите сетевого периметра информационных (автоматизированных) систем

На сайте ФСТЭК 10 марта был опубликован документ с рекомендациями по защите сетевого периметра информационных (автоматизированных) систем. Документ на 6 страниц, содержит требования, оформленные в 8 групп (символом ✳️ я отметил то, что непосредственно относится к Управлению Уязвимостями):

1. Администрирование, управление конфигурацией и эксплуатацией сетевых устройств: 1.1 администрировать пограничные устройства с изолированных рабочих мест; 1.2 использовать сертификаты или сложные пароли; 1.3 применять уникальные пароли; 1.4 контролировать и журналировать изменения конфигурации; ✳️ 1.5 выявлять и блокировать нелегитимные внешние сервисы; ✳️ 1.6 вести учёт устройств на сетевом периметре; ✳️ 1.7 управлять устройствами с истекающей поддержкой; 1.8 запретить внешнее удалённое администрирование; 1.9 согласовывать изменения с ИБ; 1.10 использовать безопасные протоколы мониторинга.

2. Повышение устойчивости к DDoS-атакам: 2.1 настроить блокировку неразрешённого трафика; 2.2 фильтровать трафик через WAF; 2.3 включить защиту от DDoS; 2.4 ограничивать подключения с одного IP; 2.5 взаимодействовать с оператором связи для противодействия DDoS.

3. Сегментация сети и контроль доступа для защиты ключевых сегментов: 3.1 сегментировать сеть VLAN и локальными сетями; 3.2 контролировать трафик через ACL; 3.3 внедрить ZTNA; 3.4 запретить удалённое администрирование ядра сети; 3.5 создать DMZ с ограниченным доступом к внутренним сегментам.

4. Резервное копирование конфигов: 4.1 назначить ответственного за резервное копирование; 4.2 хранить ≥3 копий на разных носителях, одну отдельно; 4.3 копировать ежемесячно; 4.4 определить права на копирование; 4.5 сохранять критичные конфигурации (ACL, VLAN, NAT, учетные записи); 4.6 проверять восстановление каждые три месяца.

✳️ 5. Управление уязвимостями: 5.1 реализовать управление уязвимостями по Методике анализа защищенности (ФСТЭК 25.11.2025) и Руководству по управлению уязвимостями (ФСТЭК 17.05.2023); 5.2 устанавливать обновления безопасности на пограничных устройствах и тестировать их по Методике тестирования обновлений безопасности (ФСТЭК 28.10.2022) и Методике оценки критичности уязвимостей (ФСТЭК 30.06.2025).

6. Аутентификация и управление доступом: 6.1 централизованный контроль доступа через NAC и межсетевые экраны; 6.2 многофакторная аутентификация для админ-доступа; 6.3 разграничение ролей с минимальными привилегиями.

7. Регистрация и анализ событий ИБ: 7.1 централизованный сбор и анализ событий через SIEM; 7.2 хранение детальных журналов безопасности с временными метками; 7.3 оповещение администраторов о подозрительных действиях и изменениях.

8. Регулярные учения по реагированию на инциденты для проверки их эффективности и восстановления инфраструктуры.

Интересный и подробный документ. 👍 По VM-ной части весьма примечательно, что VM-процесс для периметра рекомендуют строить в соответствии с

🔹 Руководством по Анализу защищённости. Имеются в виду периодические внешние аудиты периметра сторонней организацией с соответствующими критериями успешности? 🤔

🔹 Руководством по организации процесса управления уязвимостями в органе/организации. Был весьма удивлён, т.к. давненько не встречал прямую ссылку на него в документах ФСТЭК. 😲 Всё больше общие требования к VM-процессу, как в 117 приказе или проекте "Мероприятий и мер". 🤷‍♂️

На прошлой неделе у Jonathan Risto из SANS был занимательный пост о том, что на самом деле определяет, будет ли процесс Управления Уязвимостями/Экспозициями работать в организации или нет - это наличие эффективного принуждения к исполнению (enforcement)

На прошлой неделе у Jonathan Risto из SANS был занимательный пост о том, что  на самом деле определяет, будет ли процесс Управления Уязвимостями/Экспозициями работать в организации или нет - это наличие эффективного принуждения к исполнению (enforcement)На прошлой неделе у Jonathan Risto из SANS был занимательный пост о том, что  на самом деле определяет, будет ли процесс Управления Уязвимостями/Экспозициями работать в организации или нет - это наличие эффективного принуждения к исполнению (enforcement)

На прошлой неделе у Jonathan Risto из SANS был занимательный пост о том, что на самом деле определяет, будет ли процесс Управления Уязвимостями/Экспозициями работать в организации или нет - это наличие эффективного принуждения к исполнению (enforcement). Jonathan описывает ситуацию, когда в организаций вроде как есть всё необходимое для нормального VM/EM процесса: сканеры, дашборды, SLA, процессы эскалации. Но принуждение к исполнению в организации слабое, и система постепенно адаптируется: дедлайны превращаются в рекомендации, ответственность ("ownership") становится предметом обсуждений, а принятые риски годами не пересматриваются ("stops being revisited"). 🫠 При этом вроде какая-то активность есть, но экспозиции практически не устраняются, растёт exposure debt.

Что имеет смысл делать в такой ситуации VM/EM-специалисту?

🔊 Попробовать достучаться до руководства. Подсветить управленческую проблему: решения принимаются, но не исполняются, поэтому экспозиции не снижаются и это приведёт к инцидентам.

📝 Формализовать всё. Фиксировать владельцев активов, конкретные задачи по исправлению, этапы исправления, risk acceptance, нарушения SLA и т.д. Это делает процессы максимально прозрачными и вы, как VM-щик, с меньшей вероятностью окажитесь "крайними".

🎯 Фокусироваться на реальном риске. Если всё не исправить, закрывать то, что действительно эксплуатируется (в первую очередь трендовые уязвимости) на наиболее критичных для бизнеса системах.

🚪 Если система не меняется - задуматься о смене работы. Это весьма грустно, но если в организации сплошная "электрификация" ("всем всё до лампочки" 😉), снизу это исправить практически нереально. А вот стать в итоге "козлом отпущения" можно запросто. Обязательно это учитывайте.

Продолжу разбирать "10 неудобных вопросов Product Manager-у по VM" из подкаста коллег из R-Vision

Продолжу разбирать 10 неудобных вопросов Product Manager-у по VM из подкаста коллег из R-Vision

Продолжу разбирать "10 неудобных вопросов Product Manager-у по VM" из подкаста коллег из R-Vision.

Вопрос 2: Вы можете гарантировать, что в вашем сканере уязвимостей не будет фолзов?

💬 Андрей Селиванов сначала пошутил, что можно гарантировать отсутствие фолзов, если просто не проводить сканирование. 😏 Далее сказал, что фолзы (некорректные детекты каких-то уязвимостей) есть в абсолютно любом решении. Причин для этого может быть масса: от некорректной информации по детектированию уязвимости в источнике данных об уязвимости (например, бюллетене RHSA вендора Red Hat или на странице с описанием уязвимости Microsoft) до ошибок при написании правил детектирования на стороне VM-вендора. Важны два параметра: процент допустимых фолзов в решении VM-вендора и то, как быстро VM-вендор их устраняет (принимая от клиентов через форму обратной связи).

#️⃣ С этим тоже не поспоришь. Но я бы посмотрел несколько шире. Фолзы - это не только про то, что какие-то конкретные правила детектирования были реализованы некорректно. Хотя, безусловно, и это тоже, и хотелось бы, чтобы такие проблемы VM-вендор ловил самостоятельно, а не только после того, как их зарепортят клиенты. 😉 Это ещё и про зрелое восприятие возможностей VM-продукта и зрелое позиционирование VM-продукта вендором.

🔹 Если сканер не детектирует какие-то уязвимости в инфраструктуре, потому что не поддерживает те или иные продукты или способы установки, это со стороны клиента может выглядеть как false negative. А может как вполне осознаваемые ограничения детектирования VM-продукта.

🔹 И с другой стороны, то, что упомянул вскользь Андрей "многое зависит от окружения, от специфических условий", когда сканер детектирует уязвимости в библиотеке, которая по факту не используется, это может восприниматься со стороны клиента как жуткие false positive ошибки. А может как особенность детектирования "потенциальных" уязвимостей сканером.

Тут, наверное, хотелось бы, чтобы мы (как VM-комьюнити) отходили от восприятия любых средств анализа защищённости как волшебных оракулов, которые выдадут все 100% имеющихся уязвимостей в инфраструктуре. Конечно же, нет. 🤷‍♂️

Детектирование всех уязвимостей конкретной инфраструктуры - это сложная задача. За которую ответственен в первую очередь VM-специалист. И VM-специалист должен понимать ограничения используемых средств анализа защищённости и выбирать наиболее адекватные из них (а не самые дешёвые 😉).

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) "10 неудобных вопросов Product Manager-у по VM"

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) 10 неудобных вопросов Product Manager-у по VM

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) "10 неудобных вопросов Product Manager-у по VM". Естественно, обсуждение шло в контексте решения R-Vision VM. Интересный формат и подборка вопросов. 🔥 Собираюсь их постепенно разобрать и добавить свои комментарии. 😉

Вопрос 1: Класс Vulnerability Management решений - это маркетинговая обёртка сканеров уязвимостей или за этим есть какие-то дополнительные технологии?

💬 Андрей Селиванов ответил в духе, что VM-решения - эволюционное развитие сканеров уязвимостей, потребность в которых возникла с увеличением количества активов (сказал, что у них есть клиент с 300 000 конечных точек и сотней миллионов уязвимостей) и увеличением разнообразия типов активов. Все уязвимости на этих активах необходимо эффективно детектировать, приоритизировать и ставить задачи на устранение. С простым сканером уязвимостей с таким объёмом справляться сложно, требуется более функциональное решение. "Но сканер - это то, по чему встречают решение в любом пилоте и у любого клиента". Важно, насколько качественно выявляются уязвимости, насколько широкое покрытие. "Если у тебя не будет нормального сканера, называться полноценным VM-решением - ну такое себе".

#️⃣ В целом, согласен со сказанным. Особенно в части качества детектирования. 👍 Единственное я бы выделил такие формальные признаки сканера уязвимостей и VM-решения: если средство анализа защищённости (САЗ) работает в парадигме отдельных сканов - это сканер уязвимостей. Классический пример - Nessus. А если САЗ хранит картину текущего состояния всей инфраструктуры (активов и уязвимостей на них), позволяет делать выборки по уязвимостям, делать приоритизацию уязвимостей, заводить и отслеживать задачи на устранение (через встроенную тикетницу или через интеграции) и производить прочую высокоуровневую обработку, то это уже решение класса Vulnerability Management. Потому что это решение реализует внутри себя Vulnerability Management процесс. Ну или, во всяком случае, вендор решения это декларирует и к этому стремится. 😉

При этом я НЕ считаю, что любое VM-решение априори лучше любого сканера уязвимостей и должно стоить дороже.

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

🔹 В свою очередь VM-решение может лишь формально реализовывать заявленную функциональность и, к примеру, не справляться с реальной нагрузкой (особенно если его навайбкодили за выходные 😉). VM-решение вообще может быть опенсурсным проектом, типа Faraday Security или DefectDojo, и стоить (ну, в теории 😏) 0 руб.

Так что маркетинговые категории мало чего значат на самом деле. Нужно смотреть в суть.