Сергей Уздемир, 24/04/24
В прошлом году ФСТЭК России разработала и утвердила методический документ по организации управления уязвимостями (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 в максимально возможное число организаций на основе использования отечественных сканеров с открытыми базами проверок и метриками оценки и приоритизации уязвимостей, а также активной и координирующей роли регулятора в этом процессе.
