Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ): предварительная схема по текстовому описанию. Конечно, требуется дальнейшая детализация и расширение. Мне в первую очередь интересна оценка используемых средств детектирования. 😎
Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ). Как правильно отслеживать и развивать Vulnerability Management процесс? Имхо, нет единственно правильного способа. Если уязвимости в инфраструктуре своевременно исправляются, аудиторы вас нахваливают, а пентестеры грустят, значит всё норм. 👍 Но некоторые свои соображения я сформулирую под названием БОСПУУ. 😉
Общая оценка состоит из 3 компонентов:
🔸 Оценка используемых средств детектирования уязвимостей (полнота базы детектов, достаточность способов детектирования, оперативность доставки детектов)
🔸 Оценка охвата инфраструктуры VM-процессом (несканируемые активы и сети, активы без ответственных, активы без SLA по устранению уязвимостей, уязвимости без тасков)
🔸 Оценка выполнения SLA по патчингу для скоупов активов. Каждый скоуп разбиваем на группы активов по критичности: целевые, ключевые, обычные. Для каждой группы отслеживаем выполнение SLA по плановому и приоритетному исправлению уязвимостей.
upd. Схема
По поводу критичной уязвимости Authentication Bypass - Veeam Backup & Replication (CVE-2024-29849). Veeam B&R - клиент-серверное ПО для централизованного резервного копирования виртуальных машин в средах VMware vSphere и Microsoft Hyper-V.
Уязвимость нашли в компоненте Backup Enterprise Manager - веб-консоль для управления и создания отчетов. Неаутентифицированный злоумышленник может войти в веб-консоль от имени любого пользователя. CVSS 9.8.
🔸 Уязвимость была исправлена вендором 21 мая.
🔸 Через 3 недели, 10 июня, исследователь под ником SinSinology выложил в своём блоге разбор этой уязвимости (на основе анализа патча) и PoC для неё.
Подтверждений эксплуатации уязвимости в реальных атаках пока нет, но, вероятнее всего, скоро будут. Компрометация бэкапов не менее лакомая цель, чем компрометация виртуальной инфраструктуры.
До 2022 года продукты Veeam были популярны в России и наверняка остаётся ещё много инсталляций. 🤔
Обязательно обновляйтесь!
По случаю пятницы поделюсь одним своим загоном. В одной небольшой азиатской стране есть небольшой ИБ-вендор, который предлагает сервис по управлению поверхностью атаки и редтимингом. И ещё публикует крутые ресёрчи по уязвимостям. И всё у них хорошо кроме названия.
Их название с точностью до одной буквы совпадает с кратким названием журнала, который издаёт одна религиозная организация, признанная в России экстремистской. Журнал этот вполне известный, в книге рекордов значится как "самый распространяемый в мире". Полное название журнала (на русском) есть в списке экстремистских материалов.
И вот каждый раз, когда надо бы этого вендора публично упомянуть я загоняюсь:
🔸 Просто писать как есть. Слово общеупотребительное, на английском, разница в букву - вроде норм. Или не норм? 🤔
🔸 Написать, что это вот не те, которые запрещённые и в реестре, просто совпадение. Вроде правильно, но мегастранно. 🤷♂️
🔸 Вообще не ссылаться на них от греха подальше. 🙈🙂
По поводу критичных уязвимостей Remote Code Execution - VMware vCenter (CVE-2024-37079, CVE-2024-37080). vCenter это продукт для централизованного управление виртуальной инфраструктурой на платформе VMware vSphere.
Обе уязвимости были исправлены 17 июня. У них одинаковое описание и CVSS 9.8.
Уязвимости связаны с переполнением кучи в реализации протокола DCERPC. Злоумышленник, имеющий сетевой доступ к vCenter Server, может отправить специально подготовленный сетевой пакет и потенциально получить RCE.
Публичного эксплоита и признака эксплуатации вживую пока нет, однако:
🔸 Уязвимости очень похожи по описанию на прошлогоднюю эксплуатируемую RCE уязвимость vCenter (CVE-2023-34048). И CVSS вектор такой же.
🔸 "Скриншот vSphere Client", интерфейса для vCenter, стал своеобразным мемом злоумышленников, подтверждающим, что в ходе атаки им удалось скомпрометировать виртуальную инфраструктуру организации. Цель очень лакомая!
Обязательно обновляйтесь!
Ещё немного про то, что не все сканеры одинаково хороши. Так как сейчас нет обязательной или даже добровольной системы сертификации сканеров уязвимостей, то под наименованием "сканер уязвимостей" может скрываться что угодно.
Доводя до абсурда, можно написать утилиту, которая будет детектировать одну CVE-шку, приделать к ней вебгуй с дашбордами и презентовать это как "сканер уязвимостей", альтернативу ТОП-овым решениям на рынке. Уязвимость ищет? Ищет! А то что одна - а сколько вам надо? Не знаете? Ну так чего теперь. 🤪
А если перелицевать и соединить опенсурсные утилиты, которые уязвимости действительно детектят (GVM/OpenVAS, OpenSCAP/Wazuh, Nmap с плагинами, Nuclei и т.д.), вообще не прикопаешься. 😉 С хостами софтина взаимодействует, список уязвимостей выдаёт. Достаточно ли хорошо? А фиг его знает. 🤷♂️
Имхо, для того, чтобы сравнивать возможности по детектированию уязвимостей, нужно научиться эти возможности адекватно и единообразно описывать. Нужна методика. 🤔
Не сканер детектирует уязвимости, а VM-щик детектирует уязвимости с помощью сканера. Такая вот невероятно глубокая мысль. 🙂 Сканер уязвимостей это просто инструмент. Если этот инструмент не выполняет заявленные функции, это не снимает ответственность с того, кто этот инструмент закупил и использует.
Представим ситуацию: сканер фолснегативил при детекте уязвимости, через неё поломали организацию. VM-щик бежит с претензией к VM-вендору. После боданий, если получилось доказать проблему, вендор извиняется и выпускает обновлённый детект. И всё. А из-за этой уязвимости возможно всю инфру пошифровали. 🤷♂️ И кто в этой ситуации будет крайним и будет иметь бледный вид?
Пока нет обязательной сертификации VM-решений, предъявляющей требования к детектированию уязвимостей, и/или ответственности за некачественный детект, оценка качества работы решений целиком лежит на клиенте. И, к сожалению, делать это нужно не только перед закупкой, но и в течение всего периода эксплуатации.
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.