Наполнение и обогащение базы уязвимостей 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-логикой.