Контроль качества базы уязвимостей R-Vision VM и задействованные группы специалистов. Завершаю накидывать по итогам вебинара.

🔬 Качество детектирования уязвимостей проверяют на 700+ стендах. С конкурентами сравниваются (упомянули Nessus, Rapid7 Nexpose). Есть дежурные, которые отрабатывают по false positive ошибкам.

🌐 Покрытие базы уязвимостей можно посмотреть на публичном портале, обновляемом раз в 2 недели.

👂 В новой версии R-Vision VM можно будет искать по базе уязвимостей.

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

👷‍♂️ Инженеры - занимаются развитием исследовательской лаборатории.

🧪 Аналитики и Исследователи - разбирают эксплоиты и логику детектирования. Аналитики фокусируются на режиме Аудит, а Исследователи на режиме Пентест.

👨‍💻 Разработчики - занимаются разработкой движка детектов.

Общее число специалистов около 30.

Бонус: несколько моментов из QA сессии

Наполнение и обогащение базы уязвимостей R-Vision VM. Продолжу накидывать по итогам вебинара.

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

👁‍🗨 При формировании базы используют как открытые источники (такие как NVD и БДУ), так и закрытые - технические партнёрства и платные базы (в т.ч. по уязвимостям ушедших вендоров, таким как SAP). Состояние источников отслеживается. Правила детектирования старых уязвимостей не исключают (даже для EOL-продуктов).

📶 Добавление нового фида может быть итеративным: сначала детекты уязвимостей, потом описание, how to fix и т.п.

💎 Информация по уязвимостям обогащается: CVSS, EPSS, наличие эксплоитов (без ссылок), трендовость, рекомендации по устранению, русификация.

🪛 Периодически требуется правка правил детектирования со стороны R-Vision ("патчинг уязвимостей").

⏱️ Обновляют базу уязвимостей раз в сутки (будут быстрее).

Общие сведения о базе уязвимостей R-Vision VM. Выпишу некоторые моменты по итогам сегодняшнего вебинара.

🎯 При формировании своей базы уязвимостей R-Vision делали упор на качестве (актуальности данных и корректности логики детектирования), независимости от единственного источника (к которому могут закрыть доступ), максимизации охвата ИТ-инфраструктуры заказчиков и быстроте добавления новых источников.

🧠 Смотрели разные варианты и форматы описания правил детектирования, включая CSAF CVRF. В результате приняли решение пилить самим в OVAL-like формате (в JSON с упрощёнными проверками, +- похоже на мои задумки с SOVA). При этом они могут быстро добавлять источники в формате OVAL - срок от 7 дней. Говорят, что прямо в ходе пилота добавляли правила детектирования уязвимостей ОС. Но вообще для формирования правил детектирования и обогащения базы могут принимать и конвертировать любые фиды.

✅ Compliance-проверки они пишут не в своём OVAL-like формате, а на YAML с VRL-логикой.