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

На конференции IT Elements эксперты компании Инфосистемы Джет представили "Фреймворк антихрупкой ИТ-архитектуры", учитывающий состояние процесса Управления Уязвимостями в организации

Добавить комментарий

На конференции IT Elements эксперты компании Инфосистемы Джет представили Фреймворк антихрупкой ИТ-архитектуры, учитывающий состояние процесса Управления Уязвимостями в организации

На конференции IT Elements эксперты компании Инфосистемы Джет представили "Фреймворк антихрупкой ИТ-архитектуры", учитывающий состояние процесса Управления Уязвимостями в организации. Фреймворк включает в себя 7 стратегий по четырём направлениям:

🔹 Подготовка к вторжению - 1. Системное развитие и контроль, 2. Подготовка и прогнозирование.
🔹 Слева от вторжения - 3. Вовлечение и нападение, 4. Защита, замедление, сдерживание.
🔹 Справа от вторжения - 5. Обнаружение и реагирование.
🔹 После вторжения - 6. Восстановление, 7. Адаптация и перестройка.

Эти стратегии раскладываются в 33 домена, которые, в свою очередь, раскладываются в 390 практик.

Чтобы замерить индекс антихрупкости для своей организации, можно воспользоваться специальным интерактивным опросником. Индекс оценивает способность компании пережить кибератаку, продолжать работу в её условиях и восстановиться после неё. По итогам заполнения опросника получаем индекс от 0 до 100%, разбор по направлениям защиты и сравнение с другими участниками. Отраслевой уровень обновляется автоматически по мере накопления ответов респондентов. Индекс рассчитывается по открытой методике. Опросник должен заполнять CISO. Вопросы однотипны, варианты ответов: "Да", "Частично", "Нет", "Неприменимо", "Не знаю".

Теперь пройдёмся по 13 практикам, которые непосредственно связаны с Управлением Уязвимостями. Они находятся в разделе Слева от вторжения -> 4. Защита, замедление, сдерживание -> 4.4 Непрерывная работа с уязвимостями.

📄 Формализация процесса, ответственные за устранение и сроки устранения

4.4-1 Регламентирован и реализуется процесс управления уязвимостями, определяющий порядок их выявления, оценки критичности, планирования и контроля устранения. Определяются ответственные за устранение уязвимостей и реализацию исправлений, а также целевые сроки, согласованные службами ИБ и ИТ

В опроснике: 49. Регламентирован и реализуется процесс управления уязвимостями. Определены ответственные за устранение уязвимостей и реализацию исправлений, а также целевые сроки, согласованные службами ИБ и ИТ

📄 Задачи на сканирование

4.4-2 Определен перечень, приоритеты и сроки сканирования каждого актива/типов активов. В область сканирования включены все активы, обеспечивающие критически значимые процессы организации

В опроснике нет.

📰 Отслеживание информации об уязвимостях

4.4-3 Определены источники информации об уязвимостях (например, БДУ ФСТЭК России, уведомления от регуляторов, сайты производителей ПО, каналы СМИ и др.). Информация из этих источников систематически анализируется на предмет применимости к активам организации, выявленные релевантные уязвимости регистрируются

В опроснике нет.

🚨 Экстренная обработка уязвимостей

4.4-4 Документирована и реализуется процедура экстренной обработки критических уязвимостей, определяющая порядок оповещения ИБ и ИТ, экстренной оценки применимости уязвимости, реализации временных защитных мер и координации действий с процессом кризисного реагирования.

В опроснике: 50. Документирована и реализуется процедура экстренной обработки критических уязвимостей, определяющая порядок оповещения ИБ и ИТ, экстренной оценки применимости уязвимости, реализации временных защитных мер и координации действий с процессом кризисного реагирования.

🔎 Сканирование на наличие уязвимостей

4.4-5 Функционирует процесс регулярного автоматизированного поиска уязвимостей. Поиск выполняется автоматизированными средствами, использующими актуальные базы данных (сканеры уязвимостей).

В опроснике: 51. Функционирует процесс регулярного автоматизированного поиска уязвимостей. Поиск выполняется автоматизированными средствами, использующими актуальные базы данных.

💿 Базовые образы

4.4-6 Процесс управления уязвимостями включает процедуры проверки и устранения уязвимостей в базовых образах инфраструктуры, используемых для развертывания корпоративных информационных систем.

В опроснике нет.

⚖️ Продвинутая приоритизация уязвимостей

4.4-7 Приоритизация устранения уязвимостей выполняется по риск-ориентированным критериям, включая критичность актива, последствия эксплуатации, наличие доступных способов эксплуатации и техническую оценку уязвимости. Приоритеты используются для определения сроков устранения и контроля выполнения.

В опроснике: 52. Приоритизация устранения уязвимостей выполняется по риск-ориентированным критериям. Приоритеты используются для определения сроков устранения и контроля выполнения.

🔐 Сканирование с аутентификацией

4.4-8 Для обнаружения уязвимостей применяется аутентифицированное сканирование узлов, при котором средство сканирования получает контролируемый доступ к системе для более точного выявления уязвимых компонентов и конфигураций.

В опроснике нет.

🔗 Интеграция с GRC

4.4-9 Данные об уязвимостях автоматически синхронизируются с реестром рисков или системой управления рисками (GRC-системой). Изменение статуса уязвимости приводит к пересчету параметров риска и созданию или обновлению карточки риска.

В опроснике нет.

🎫 Интеграция с Task Tracker

4.4-10 Реализована интеграция инструментов сканирования уязвимостей с системой управления задачами. Задачи на устранение уязвимостей формируются автоматически, приоритет задач определяется критичностью уязвимости и значимостью актива.

В опроснике нет.

↪️ Компенсирующие меры

4.4-11 Для уязвимостей, устранение которых невозможно или небезопасно, определяется и применяется набор компенсирующих мер, выбор которых документируется и привязывается к конкретной уязвимости и активу.

В опроснике нет.

💭 План снижения риска

4.4-12 Для унаследованных систем, которые невозможно привести к актуальному уровню безопасности, разработаны и выполняются планы снижения риска. Планы определяют целевое состояние системы (вывод из эксплуатации или замена) и устанавливают временные меры защиты на период ее эксплуатации.

В опроснике нет.

⏱️ Отслеживание сроков устранения

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

В опроснике: 53. Осуществляется периодический контроль соблюдения целевых сроков устранения уязвимостей. Устранение выявленных уязвимостей периодически контролируется.

В целом, довольно толковый набор практик. 👍 Единственное, не очень понятно, почему практик больше, чем вопросов в опроснике. Возможно, отобрали самое важное, а может, опросник будут расширять. 🤷‍♂️

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

Добавить комментарий

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

Коллеги из R-Vision выпустили новую версию системы управления уязвимостями R-Vision VM 6.6. В новости на официальном сайте сделан акцент на следующих улучшениях:

🌐 Базовый аудит веб-приложений: обнаружение и инвентаризация веб-ресурсов, выявление связанных уязвимостей.

🐳 Аудит контейнерных сред Docker и Kubernetes, "включая проверку в runtime". Сбор данных о составе и состоянии контейнерной среды, выявление связанных уязвимостей. Результаты отображаются в карточке соответствующего хоста.

💻 Мобильный сканер для контроля уязвимостей в закрытых сегментах без постоянного доступа из центральной VM-системы. Может использоваться на объектах КИИ, в удалённых филиалах, а также для выездных аудитов, пилотных и временных проектов. Устанавливается на ноутбук и позволяет проводить аудит внутри изолированного контура. Поддерживаются режимы сканирования White Box, Black Box, Compliance и Web-аудит. Результаты инвентаризации активов и выявленные уязвимости передаются в центральную инсталляцию R-Vision VM. Рассчитан на проверку до 2000 хостов.

Также заявлены:

🔹 расширение инвентаризации ESXi, vCenter и сетевого оборудования;
🔹 обновление Compliance-проверок;
🔹 обновление карточек хоста;
🔹 новые возможности анализа и экспорта данных об уязвимостях;
🔹 доработка политик автоматизации, интеграций и дашбордов;
🔹 обновление агента из интерфейса;
🔹 мастер первичной настройки.

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

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

Добавить комментарий

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

Закончу разбирать основной VM-ный пункт "3.3. Управление уязвимостями (КУ)" из недавно опубликованного методического документа "Мероприятия и меры по защите информации, содержащейся в информационных системах", и сравню его с версией из февральского драфта документа, чтобы отследить принятые правки. В прошлый раз я расписал Цели и Требования к реализации, сегодня рассмотрю Требования к документированию и Требования к усилению.

ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

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

👥 Подразделения / работники

"перечень подразделений (работников), ответственных за организацию и контроль управления уязвимостями, а также участвующих в реализации процессов управления уязвимостями, их обязанности (функции) и права (полномочия);"

Получается, что подразделения (работники) делятся на:

🔹 ответственных за организацию и контроль управления уязвимостями;
🔹 участвующих в реализации процессов управления уязвимостями.

Для каждого подразделения (работника) необходимо расписать:

🔹 обязанности (функции);
🔹 права (полномочия).

Напрашивается таблица следующей структуры:

Подразделение (работник); За что отвечает; В реализации каких процессов участвует; Обязанности (функции); Права;

📋 Операции

Требования по документированию операций имеют идентичную структуру:

"описание операций, осуществляемых при {название этапа (подпроцесса)}, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при {название этапа (подпроцесса)}"

Буквально вот так:

"описание операций, осуществляемых при мониторинге уязвимостей и оценке их применимости, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при мониторинге уязвимостей и оценке их применимости;
описание операций, осуществляемых при оценке уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при оценке уязвимостей;
описание операций, осуществляемых при определении методов и приоритетов устранения уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при определении методов и приоритетов устранения уязвимостей;
описание операций, осуществляемых при устранении уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при устранении уязвимостей;
описание операций, осуществляемых при контроле устранения уязвимостей, перечень исполнителей операций, продолжительность реализации, входные и выходные данные, используемые при контроле устранения уязвимостей;"

Напрашивается таблица следующей структуры:

Этап (подпроцесс); Наименование операции; Описание операции; Перечень исполнителей; Продолжительность реализации; Входные данные; Выходные данные;

Типовые операции и их описания можно взять из Таблиц 3.1, 4.1, 5.1, 6.1, 6.2, 7.1, 7.2 "Руководства по организации процесса управления уязвимостями в органе (организации)" от 17 мая 2023 г. (далее для краткости буду обозначать документ как РУУ23).

🗺️ Схемы

"схемы взаимодействия подразделений (работников) при реализации операций по управлению уязвимостями."

Интересно, что здесь требуются схемы взаимодействия при реализации операций. А операция, в терминах РУУ23, - это что-то более-менее атомарное, чем занимается один исполнитель. Например, "Анализ информации об уязвимости" или "Корректировка механизмов мониторинга". Это не тот уровень, где подразумевается взаимодействие. Есть подозрение, что авторы здесь имели в виду не конкретные операции, а этапы (подпроцессы). По аналогии с тем, как этапы разрисованы в РУУ23 на Рисунках 2.2, 3.1, 4.1, 5.1, 6.1, 6.2, 7.1, 7.2. Здесь требуется разъяснение регулятора, какие именно схемы должны быть приведены в регламенте. Текущая формулировка неоднозначна.

📜 Какие различия с драфтом?

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

Остальные правки касались только орфографии.

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

ТРЕБОВАНИЯ К УСИЛЕНИЮ

Насколько вообще обязательны требования из этого раздела? Читаем в сноске в пункте 3.1:

"Усиления мероприятий (процессов) по защите информации, приведенные в подразделах «требования к усилению» раздела 3, применяются по решению оператора (обладателя информации) для повышения эффективности реализации мероприятий по защите информации и повышения уровня защищенности информационных систем и содержащейся в них информации, а также для снижения возможности нарушителей по реализации угроз безопасности информации.

⚙️ Автоматизация

1) для управления уязвимостями используются автоматизированные системы управления уязвимостями;

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

👾 Анализ угроз

2) для мониторинга уязвимостей применяются средства анализа угроз, в том числе TI-платформы;

Фактически это требование означает, что управление уязвимостями должно стать частью CTEM (Continuous Threat Exposure Management) и учитывать данные о реальной эксплуатации уязвимостей: какие из них уже используются атакующими, какие техники применяются и в каких сценариях. В связке с анализом путей атаки это позволяет понимать, как уязвимости используются злоумышленниками для проникновения к целевым активам, и соответственно приоритизировать их устранение.

🗃️ CMDB

3) для оценки применимости уязвимостей используются данные, содержащиеся в автоматизированных системах сбора и хранения данных об объектах инвентаризации и их конфигурациях (СMDB-системы); (в документе в "СMDB" кириллическая С 🤷‍♂️)

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

🤝 Смежные процессы

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

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

📜 Какие различия с драфтом?

В релиз не вошло требование "для мониторинга уязвимостей и оценки их применимости используются результаты контроля (оценки) уровня защищенности информации;"

Очень жаль, что убрали этот пункт, потому что результаты пентестов и независимого анализа защищённости часто выявляют уязвимости, которые по каким-то причинам не обнаруживаются штатными САЗ, используемыми в процессе управления уязвимостями. Такие находки являются индикатором проблем в процессе: недостаточного покрытия активов, низкого качества детектирования или несоблюдения сроков устранения. Они позволяют объективно оценить эффективность VM-процесса и улучшить его.

Остальные исправления касаются опечаток и косметических изменений.

---

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

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

1 комментарий

В этот четверг, 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 тоже расскажем и покажем продукты, которые его реализуют. 😉

Продолжу разбирать "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"

1 комментарий

Смотрю подкаст коллег из 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 руб.

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