Оглавление
В прошлом году ФСТЭК России разработала и утвердила методический документ по организации управления уязвимостями (VM) [1], который устанавливает цикл этапов работ по VM. Излагаемые в нем подходы универсальны для любых организаций и тесно пересекаются с зарубежными стандартами, в частности с ISO/IEC 27002, Control 8.8 – Management of Technical Vulnerabilities.
Автор: Сергей Уздемир, заместитель генерального директора по ИТ, АЛТЭКС-СОФТ
Методический документ ФСТЭК России по организации управления уязвимостями подлежит прямому применению в информационных системах государственных органов, субъектов критической информационной инфраструктуры, однако можно прогнозировать, что область его применения будет значительно шире.
Несколько раньше в российской профессиональной сфере ИБ, как и во всем мире, аббревиатурой VM стали именовать сканеры безопасности с расширенными функциями аналитики и представления результатов. При продвижении этого класса продуктов акцент сместился в область прикладного расчета критичности уязвимостей и инструментов организации работ по их исправлению, отодвинув на второй план задачи детектирования и оценки применимости уязвимостей. Разберемся с ожиданиями и основными проблемами при реализации некоторых этапов цикла VM с использованием данных средств.
Сканирование на наличие уязвимостей и оценка их применимости
Зачастую приходится сталкиваться с мнением, что проблема достоверного детектирования уязвимостей ПО общего пользования для рабочих станций и серверов – вопрос тривиальный и давно решенный большинством производителей сканеров, тем не менее с этим нельзя согласиться, и вот почему.
Несколько лет назад, когда в России преобладало зарубежное ПО именитых вендоров с устоявшейся культурой публикации уязвимостей, разработчикам сканеров при формировании правил детектирования уязвимостей приходилось решать множество сложных и порой противоречивых задач. Причина кроется в различных методах формирования правил проверок, и прежде всего это касается сложных продуктов с большим количеством заимствованных компонентов, в том числе Open Source, например операционных систем.
Первый метод – «вендор всегда прав», то есть в список проверок включать только подтвержденные разработчиком уязвимости, формально дополняя их данными из официального ресурса (Банка данных угроз) ФСТЭК России. Однако этот метод сильно зависим от того, насколько оперативно и качественно разработчик подходит к публикации данных об уязвимостях своего ПО.
Второй метод – экспертиза, основанная на декомпозиции ПО на компоненты, каждый из которых дает свое самостоятельное подмножество проверок. Например, если в составе продукта используется Open Sourсe, то список проверок формируется на основе данных Community, дополнительно учитывая базы данных эксплойтов, тематические форумы и полуофициальные источники. В теории это выглядит более привлекательным, но может привести к большому количеству ложноположительных детектирований, так как команда разработчиков сканера не всегда может достоверно определить степень модификации привлеченного (заимствованного) ПО и возможность эксплуатации уязвимостей дочернего компонента через функции родительского ПО и его окружения.
Текущие реалии внесли свои особенности в процесс формирования правил детектирования уязвимостей: так, для большинства зарубежного ПО отсутствует техническая поддержка и, соответственно, официальное информирование об уязвимостях в виде бюллетеней безопасности. Появились сложности с формированием стендов для тестирования, связанные с невозможностью получения лицензий на ПО и оборудование.
Российские решения привносят свою дополнительную специфику:
отсутствие или несовершенство практики публикации бюллетеней безопасности, в том числе оценки применимости заимствованных проприетарных и Open Source – компонентов, выпуска «пожарных» обновлений для наиболее критичных уязвимостей;
преобладание обновлений безопасности в виде новых версий ПО, что, вероятно, связано со сложностями процедуры внесения изменений в сертифицированные версии;
неточности в описаниях, некорректные ссылки на иностранные классификаторы CVE, CWE и экспертные базы.
Все это приводит к тому, что два разных сканера могут давать различающиеся результаты поиска уязвимостей, и этот результат может отличаться (в большую сторону, если сканер использует декомпозиционный метод формирования правил проверок) от бюллетеней безопасности разработчика и баз данных регулятора, что, в сущности, нормально, так как детектирование той или иной уязвимости инфраструктурным сканером безопасности – это всегда некоторая вероятностная оценка, причем в процессе поиска потенциальных уязвимостей ошибочные оценки false positive лучше, чем false negative.
В качестве рекомендаций можно выделить следующее:
Определить приоритет результатов автоматизированного детектирования и иных источников информации об уязвимостях для каждой платформы (ОС или аппаратной), а в идеале – для каждого используемого продукта в соответствии со степенью доверия к ним. По мнению разработчиков сканеров уязвимостей, приоритет сканера должен быть выше как минимум для:
— зарубежных платформ и продуктов;
— продуктов разработчиков, несистематически публикующих данные об уязвимостях;
— ПО с открытым исходным кодом, в том числе встроенного или в составе репозиториев отечественных ОС.
Сравнивать результаты сканирования в разных режимах: агент/безагент, с привилегированными учетными данными/без учетных данных.
Использовать сканеры с базой уязвимостей в открытом формате OVAL, что облегчит разбор спорных детектов.
Оценка уязвимостей
Оценки по CVSS по базовым метрикам (Base Score), полученные из разных источников, могут существенно различаться, часто эта ситуация проявляется в случаях уязвимостей ядра Linux. Эксперты при формировании универсального описания могут повышать ее оценки, разработчики, наоборот, понижать.
Рассмотрим конкретную уязвимость BDU:2022-05539 (CVE-2022-39842): RCE-уязвимость функции pxa3xx_gcu_write ядра операционной системы Linux. Ее CVSS v.3 Base score в БДУ ФСТЭК России равен 9.8 (критический), а разработчики ОС оценили критичность этой уязвимости в своих дистрибутивах в широком диапазоне с преобладанием средних значений 6.1–6.5.
Существует единство мнений, что в реальных условиях эксплуатации оценка по CVSS Base Score должна пересчитываться. Большим шагом в этом направлении является утвержденная ФСТЭК России Методика оценки уровня критичности уязвимостей…, в то же время ее применение может быть технически сложным. Оценки, связанные с определением доли уязвимых компонентов разного типа от общего числа, позволяют вполне достоверно оценить защищенность ИС в среднем, но могут серьезно понизить оценку единичной, но сверхкритичной RCE-уязвимости на сверхважном активе. Кроме того, для определения критичности по методике ФСТЭК нужно «в моменте» получить результаты сканирования всей ИС – в больших сетях это достаточно сложно, есть проблема устаревания результатов сканирования, что опять-таки может привести к неверным оценкам.
В целом многие методики оценки уязвимостей, реализованные в том числе и в некоторых сканерах (VM-решениях), – это «надстройки над CVSS», в которых заложена концепция усреднения субъективных экспертных оценок отдельных метрик CVSS, которая потенциально может привести к пониженной оценке уязвимостей с большими возможностями эксплуатации.
Общая рекомендация в оценке критичности звучит так: не ограничиваться только интегральной оценкой CVSS, но учитывать и отдельные метрики CVSS, другие атрибуты уязвимостей. Наиболее правильным будет формирование определения критичности на основе анализа рисков и угроз, связанных с эксплуатацией уязвимостей.
Одним из простых и доступных вариантов переопределения оценки CVSS является ее пересчет на основе весовых коэффициентов, основанных на типе уязвимости (варианте эксплуатации). В частности, многочисленные экспертные «топы» (списки часто используемых уязвимостей) позволяют установить следующий рейтинг типов уязвимостей.
Remote Code Execution (удаленное выполнение кода).
Elevation of Privilege (повышение привилегий).
Authentication Bypass (обход аутентификации).
Security Feature Bypass (обход функций безопасности).
Существуют более сложные математические модели и открытые проекты, такие как Vulristics, которые производят оценку уязвимостей на основе общедоступной информации об их атрибутах и эксплойтах.
Установка приоритетов устранения
Многие эксперты отмечают, что оценка CVSS и «границы» категорий критичности установлены таким образом, что для большого количества уязвимостей определяется критический или высокий уровень, особенно это характерно, когда оценка производится по СVSS v.2. В частности, на дату публикации материала в БДУ ФСТЭК России больше половины (55,9%) всех опубликованных уязвимостей имеет критическую и высокую степень опасности. Это приводит к тому, что приоритетному исправлению могут подлежать большинство детектированных уязвимостей, что не выглядит логичным.
В то же время если мы проанализируем списки наиболее часто эксплуатируемых уязвимостей, например Top Routinely Exploited Vulnerabilities (CSA), Qualys Top 20 Most Exploited Vulnerabilities, Kaspersky threads, то увидим, что в них с регулярным постоянством попадают достаточно «старые» уязвимости не с самой высокой оценкой по Base Score, например CVE-2017-11882: Microsoft Office Memory Corruption Vulnerability, CVE-2017-8570: Microsoft Office Remote Code Execution Vulnerability, которые имеют Base Score = 7.8.
Таким образом, целесообразно дополнить основанный на CVSS принцип приоритизации уязвимостей дополнительными правилами, смысл которых будет заключаться в попытке выявления наиболее «эксплуатабельных» уязвимостей. Сканеры (VM-решения) и экспертные базы предоставляют достаточное количество атрибутов уязвимостей для организации подобного рода фильтрации.
Примером может являться правило: критической считать любую уязвимость со следующими атрибутами:
тип уязвимости – Remote Code Execution, Elevation of Privilege, Authentication Bypass;
CVSS вектор атаки (AV) = N (сетевой);
CVSS влияние на другие компоненты системы (S) = С (оказывает);
CVSS доступность средств эксплуатации (E) = H (высокая).
В завершение можно отметить тенденцию в западных VM-решениях, которые все больше становятся продуктами «для узкого круга лиц». При декларируемом выборе варианта приоритизации: с высоким рейтингом CVSS, с наиболее доступными эксплойтами, на основании прогнозирования атак, нейронных сетей и т.д., модели оценки уязвимостей в них скрыты, списки наиболее критичных уязвимостей приводятся без обоснования. Кроме того, включение функционала VM только в дорогие Enterprise-редакции или лицензионные бандлы серьезно ограничивает их применение даже на внутренних рынках.
В России, с ее бурно растущей номенклатурой отечественного ПО, формирующейся культурой безопасной разработки, мы должны стремиться к другому результату – внедрению VM в максимально возможное число организаций на основе использования отечественных сканеров с открытыми базами проверок и метриками оценки и приоритизации уязвимостей, а также активной и координирующей роли регулятора в этом процессе.
ITSec_articles