Новое исследование, проведенное на этой неделе, наверняка вызовет у команд безопасности предприятий еще больше вопросов о том, насколько разумно полагаться только на оценки уязвимостей в Национальной базе данных уязвимостей (NVD) при принятии решений о приоритетности исправлений.
Анализ 120 CVE с оценками CVSS v3, проведенный компанией VulnCheck, показал, что почти 25 000 - или около 20% - имеют две оценки критичности. Одна оценка была получена от NIST, который поддерживает NVD, а другая - от поставщика продукта с ошибкой. Во многих случаях эти две оценки различались, что затрудняло для команд безопасности понимание того, какой из них доверять.
Высокое число конфликтов.
Примерно 56%, или 14 000, уязвимостей с двумя оценками критичности имели противоречивые оценки, то есть оценка, присвоенная NIST, и оценка, полученная от поставщика, не совпадали. Если поставщик оценивал конкретную уязвимость как умеренную, то NIST мог оценить ее как серьезную.
В качестве примера VulnCheck указал на CVE-2023-21557, уязвимость отказа в обслуживании в Windows Lightweight Directory Access Protocol (LDAP). Microsoft присвоила уязвимости «высокую» степень критичности - 7,5 по 10-балльной шкале CVSS. NIST присвоил ей оценку 9,1, что делает ее»критической» уязвимостью. Информация об уязвимости в NVD не дала никакого представления о том, почему оценки различаются, сообщает VulnCheck. База данных уязвимостей пестрит множеством других подобных случаев.
По словам Джейкоба Бейнса, исследователя уязвимостей в VulnCheck, такой высокий процент конфликтов может подрывать усилия по устранению уязвимостей для организаций, испытывающих нехватку ресурсов в командах по управлению уязвимостями. «Система управления уязвимостями, которая в значительной степени полагается на оценку по шкале CVSS, иногда будет определять приоритеты уязвимостей, которые не являются критическими» - говорит он. «Неверная приоритезация уязвимостей приводит к тому, что команды по управлению уязвимостями теряют самый важный ресурс – время».
Исследователи VulnCheck обнаружили и другие различия в том, как NIST и поставщики включают конкретную информацию о недостатках в базу данных. Они решили рассмотреть уязвимости межсайтового скриптинга (XSS) и подделки межсайтовых запросов (CSRF) в NVD.
Анализ показал, что первичный источник - обычно NIST - отнес 12 969 из 120 000 CVE в базе данных к уязвимостям XSS, в то время как вторичные источники отнесли к XSS гораздо меньше - 2 091. VulnCheck обнаружил, что вторичные источники гораздо реже указывают, что для использования XSS-уязвимости требуется взаимодействие с пользователем. Оценки дефектов CSRF показали аналогичные различия.
«Уязвимости XSS и CSRF всегда требуют взаимодействия с пользователем» - сообщает Бейнс. «Взаимодействие с пользователем является элементом оценки CVSSv3 и присутствует в векторе CVSSv3». Изучение того, как часто XSS- и CSRF-уязвимости в NVD включают эту информацию, дает представление о масштабах ошибок в базе данных, говорит он.
Одни лишь оценки критичности - не ответ.
Оценки, основанные на Common Vulnerability Severity Scale (CVSS), предназначены для того, чтобы дать командам по исправлению и управлению уязвимостями простой способ понять серьезность уязвимости программного обеспечения. Она информирует специалиста по безопасности о том, представляет ли недостаток низкий, средний или серьезный риск, и часто предоставляет контекст уязвимости, который поставщик программного обеспечения мог не указать при присвоении ошибке CVE.
Многие организации используют стандарт CVSS при присвоении баллов критичности уязвимостям в своих продуктах, а команды безопасности обычно используют эти баллы для определения порядка применения исправлений к уязвимому программному обеспечению в среде.
Несмотря на его популярность, многие ранее предостерегали от того, чтобы полагаться только на рейтинг CVSS при определении приоритетов исправлений. На сессии Black Hat USA 2022 Дастин Чайлдс и Брайан Горенк, исследователи из инициативы Zero Day Initiative (ZDI) компании Trend Micro, указали на многочисленные проблемы, такие как недостаток информации о возможности использования ошибки, ее распространенности и доступности для атак, в качестве причин, по которым одних только оценок CVSS недостаточно.
«Предприятия ограничены в ресурсах, поэтому им обычно приходится определять приоритетность выпуска исправлений» - заявил Чайлдс в интервью Dark Reading. «Однако, если они получают противоречивую информацию, они могут потратить ресурсы на исправление ошибок, которые вряд ли когда-либо будут использованы».
Организации часто полагаются на сторонние продукты, которые помогают им определить приоритетность уязвимостей и решить, что нужно исправлять в первую очередь, отмечает Чайлдс. Часто они отдают предпочтение CVSS от поставщика, а не от другого источника, например, NIST.
«Но на поставщиков не всегда можно положиться в плане прозрачности реального риска. Поставщики не всегда понимают, как развертываются их продукты, что может привести к различиям в операционном риске для объекта» - говорит он.
Чайлдс и Байнс утверждают, что при принятии решений об устранении уязвимостей организациям следует учитывать информацию из нескольких источников. Они также должны учитывать такие факторы, как наличие публичного эксплойта для уязвимости или ее активная эксплуатация.
«Чтобы точно определить приоритетность уязвимости, организации должны быть в состоянии ответить на следующие вопросы» - говорит Бейнс. «Есть ли у этой уязвимости публичный эксплойт? Эксплуатировалась ли уязвимость в кибератаках? Используется ли она в атаках шифровальщиков или APT-группами? Может ли информация об этой уязвимости попасть в Интернет?».
Источник: https://www.darkreading.com
