Журнал "Information Security/ Информационная безопасность" #1, 2024

Методический документ ФСТЭК России по организации управления уязвимостя- ми подлежит прямому применению в информационных системах государст- венных органов, субъектов критической информационной инфраструктуры, одна- ко можно прогнозировать, что область его применения будет значительно шире. Несколько раньше в российской про- фессиональной сфере ИБ, как и во всем мире, аббревиатурой VM стали имено- вать сканеры безопасности с расши- ренными функциями аналитики и пред- ставления результатов. При продвиже- нии этого класса продуктов акцент сме- стился в область прикладного расчета критичности уязвимостей и инструментов организации работ по их исправлению, отодвинув на второй план задачи детек- тирования и оценки применимости уязви- мостей. Разберемся с ожиданиями и основными проблемами при реализа- ции некоторых этапов цикла VM с использованием данных средств. Сканирование на наличие уязвимостей и оценка их применимости Зачастую приходится сталкиваться с мнением, что проблема достоверного детектирования уязвимостей ПО общего пользования для рабочих станций и сер- веров – вопрос тривиальный и давно решенный большинством производите- лей сканеров, тем не менее с этим нель- зя согласиться, и вот почему. Несколько лет назад, когда в России преобладало зарубежное ПО именитых вендоров с устоявшейся культурой пуб- ликации уязвимостей, разработчикам сканеров при формировании правил детектирования уязвимостей приходи- лось решать множество сложных и порой противоречивых задач. Причина кроется в различных методах формирования правил проверок, и прежде всего это касается сложных продуктов с большим количеством заимствованных компонен- тов, в том числе Open Source, например операционных систем. Первый метод – "вендор всегда прав", то есть в список проверок включать только подтвержденные разработчиком уязвимости, формально дополняя их данными из официального ресурса (Банка данных угроз) ФСТЭК России. Однако этот метод сильно зависим от того, насколько оперативно и качествен- но разработчик подходит к публикации данных об уязвимостях своего ПО. Второй метод – экспертиза, основан- ная на декомпозиции ПО на компоненты, каждый из которых дает свое самостоя- тельное подмножество проверок. Напри- мер, если в составе продукта использу- ется Open Sourсe, то список проверок формируется на основе данных Commu- nity, дополнительно учитывая базы дан- ных эксплойтов, тематические форумы и полуофициальные источники. В теории это выглядит более привлекательным, но может привести к большому количе- ству ложноположительных детектиро- ваний, так как команда разработчиков сканера не всегда может достоверно определить степень модификации при- влеченного (заимствованного) ПО и воз- можность эксплуатации уязвимостей дочернего компонента через функции родительского ПО и его окружения. Текущие реалии внесли свои особен- ности в процесс формирования правил детектирования уязвимостей: так, для большинства зарубежного ПО отсут- ствует техническая поддержка и, соот- ветственно, официальное информиро- вание об уязвимостях в виде бюллетеней безопасности. Появились сложности с формированием стендов для тестиро- вания, связанные с невозможностью получения лицензий на ПО и оборудо- вание. Российские решения привносят свою дополнительную специфику: l отсутствие или несовершенство прак- тики публикации бюллетеней безопас- ности, в том числе оценки применимости заимствованных проприетарных и Open Source – компонентов, выпуска "пожар- ных" обновлений для наиболее критич- ных уязвимостей; l преобладание обновлений безопас- ности в виде новых версий ПО, что, вероятно, связано со сложностями про- цедуры внесения изменений в сертифи- цированные версии; l неточности в описаниях, некорректные ссылки на иностранные классификаторы CVE, CWE и экспертные базы. Все это приводит к тому, что два разных сканера могут давать разли- чающиеся результаты поиска уязвимо- стей, и этот результат может отличаться (в большую сторону, если сканер использует декомпозиционный метод формирования правил проверок) от бюллетеней безопасности разработчи- ка и баз данных регулятора, что, в сущ- ности, нормально, так как детектиро- вание той или иной уязвимости инфра- структурным сканером безопасности – это всегда некоторая вероятностная оценка, причем в процессе поиска потенциальных уязвимостей ошибоч- ные оценки false positive лучше, чем false negative. В качестве рекомендаций можно выде- лить следующее: 1. Определить приоритет результатов автоматизированного детектирования и иных источников информации об уязви- мостях для каждой платформы (ОС или аппаратной), а в идеале – для каждого используемого продукта в соответствии со степенью доверия к ним. По мнению разработчиков сканеров уязвимостей, приоритет сканера должен быть выше как минимум для: l зарубежных платформ и продуктов; l продуктов разработчиков, несистема- тически публикующих данные об уязви- мостях; 24 • СПЕЦПРОЕКТ Управление уязвимостями: ожидание – реальность и рекомендации прошлом году ФСТЭК России разработала и утвердила методический документ по организации управления уязвимостями (VM) 1 , который устанавливает цикл этапов работ по VM. Излагаемые в нем подходы универсальны для любых организаций и тесно пересекаются с зарубежными стандартами, в частности с ISO/IEC 27002, Control 8.8 – Management of Technical Vulnera- bilities. В Сергей Уздемир, заместитель генерального директора по ИТ, АЛТЭКС-СОФТ Фото: АЛТЭКС-СОФТ 1 https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/metodicheskij-dokument-ot-17-maya-2023-g