Отечественная инициатива по поиску уязвимостей в СПО для виртуализации. Тестирование проводили специалисты компании "Базис", ИСП РАН и испытательной лаборатории "Фобос-НТ" на стенде Центра исследований безопасности системного ПО, созданного ФСТЭК России на базе ИСП РАН. Студенты МГТУ им. Баумана и ЧГУ помогали с разметкой данных и настройкой целей для фаззинга.

Проверяли nginx, ActiveMQ Artemis, Apache Directory, libvirt-exporter, QEMU. Особое внимание уделяли libvirt.

Всего выявили 191 дефект:

🔹 178 нашли SAST-ом (больше всего в ActiveMQ Artemis и Apache Directory)

🔹 13 нашли фазингом (в Apache Directory LDAP API и libvirt)

Исправления интегрировали в основные ветки проектов.

Инициатива классная. 👍 Но было бы неплохо, конечно, узнать какие из этих детектов являются эксплуатабельными уязвимостями и проконтролировать, что фиксы уязвимых компонентов дошли до связанных сертифицированных продуктов в адекватные сроки. 😉

На сайте ФСТЭК выложили финальную версию "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". Что изменилось по сравнению с драфтом в части Управления Уязвимостями?

🔻 Поправили опечатку "их сети Интернет".
🔻 В обоих пунктах появилась приписка "или в отношении таких уязвимостей реализованы компенсирующие меры".

Понятно почему появилась приписка про компенсирующие меры - не всегда уязвимости можно исправить обновлением. Но есть опасность, что этим будут злоупотреблять, т.к. не указано какие меры можно считать компенсирующими. Возможно толкование, что компенсирующие меры могут выбираться произвольно. В духе "на десктопе есть EDR, значит все уязвимости на нём скомпенсированы". 🤪 Но даже если меры будут браться строго от вендора или из БДУ непонятно как контролировать, то что они были корректно применены, а главное, что эти меры действительно препятствуют эксплуатации уязвимости. На практике это будет выглядеть так: сканер детектирует уязвимости, а IT/ИБ с покерфейсом говорят "а у нас всё скомпенсировано". 😐 Так что моё мнение - без приписки было лучше, не нужно было создавать такую лазейку.

Также остался вопрос с "датой публикации обновления (компенсирующих мер по устранению)". Такой даты нет в БДУ (равно как и в других базах уязвимостей). Непонятно откуда её массово забирать, чтобы автоматически отслеживать, что организация укладывается в сроки. Вряд ли источник с датами появится, так что видимо на практике в VM-решениях будут использовать какую-то другую дату (например дату заведения уязвимости). А в случае инцидента это будет повод для лишних разбирательств. Имхо, зря это сразу не прояснили.

На эту же тему может быть интересная ситуация: допустим выходит обновление в котором вендор втихую исправляет уязвимость критического уровня опасности. А о существовании этой уязвимости становится известно, допустим, через полгода. В момент публикации данных об этой уязвимости у организации сразу получается просрочка. 🤷‍♂️ Просто потому, что используется дата, привязанная к обновлению, а не к уязвимости. Надумана ли такая ситуация? Да нет, "silent patches" проблема достаточно распространенная.

В этом, правда, есть и позитивный момент. Чтобы не попасть в такую ситуацию организации придётся выстраивать Patch Management процесс независящий от уязвимостей. И с неплохими требованиями регулярности обновлений: 30 дней для хостов на периметре, 90 дней для десктопов и серверов. 😏

PS: Также pdf-документ выпустили как-то странно, так что по нему не работает поиск. По odt-документу поиск работает нормально.