1 of 14

Управление уязвимостями

в новых реалиях

Vulns.io VM

Добрый день, уважаемые участники Инфофорума. Меня зовут Андрей Никонов, я представляю компанию Фродекс, и занимаюсь аналитикой данных об уязвимостях программного обеспечения в рамках развития российской системы управления уязвимостями Vulns.io VM.

В своем докладе я от лица вендора отечественной системы управления уязвимостями хочу рассказать о том, с какими проблемами столкнулся российский IT сегмент и какие вопросы на сегодняшний день являются наиболее важными для рынка систем VM.

На всякий случай, поясню, что система управления уязвимостями предназначена для сканирования IT-инфраструктуры и поиска уязвимостей программного обеспечения. Новые уязвимости появляются каждый день, их находят в самых разных программах, поэтому крайне важно следить за уровнем защищенности своей инфраструктуры с помощью данных систем.

2 of 14

Новые реалии – зарубежные VM-решения

02 vulns.io

2023

2022

2021

2020

2019

2018

2017

3 of 14

Новые реалии – зарубежные VM-решения ушли из РФ

03 vulns.io

2023

2022

2021

2020

2019

2018

2017

4 of 14

Новые реалии – рост кибератак на российские компании

04 vulns.io

2023

2022

*По данным пресс-релиза компании GroupIB

(https://www.group-ib.ru/media-center/press-releases/database-2022/)

5 of 14

Новые реалии – развитие российского ПО

05 vulns.io

2023

2022

Количество заявлений на включение ПО в Реестр за период 2016-2023 гг.

Переход на отечественные операционные системы

Также, за последний год произошел стремительный рост отечественных программных продуктов, которое создается в рамках импортозамещения, и это порождает проблему анализа защищенности данного ПО. Много ли кто из разработчиков занимается вопросом поиска уязвимостей в своих продуктах, и выпусков обновлений безопасности?

В ближайшей перспективе нас ждет переход на отечественные операционные системы, и крупные аналитики предупреждают, что натиск кибератак будет направлен на них, а значит будут возникать новые уязвимости.

Таким образом, процесс управления уязвимостями не должен отставать от импортозамещения, отечественные VM-решения должны уметь работать с операционными системами и программами российского происхождения.

Что на это может ответить рынок отечественных VM-решений? Насколько можно им доверять в вопросах сканирования российского ПО? Этот вопрос остается открытым на сегодняшний день, потому что никто открыто не публикует списки поддерживаемых ПО и не дает внятных ответов по степени покрытия российского софта, поэтому не понятно, насколько они отвечают сегодняшним вызовам.

На это есть конкретная причина. И мы, как вендор одного из VM-решений, ее видим.

6 of 14

06 vulns.io

Фундамент VM-системы

Она кроется в том, что для поддержки любого ПО системе VM необходимы данные об уязвимостях данного ПО.

Чтобы система управления уязвимостями работала как надо, необходимо собирать для нее базу данных всех уязвимостей, которые найдены на данный момент. Очень важно, чтобы эта база постоянно обновлялась и была полной, потому что если в ней не будет актуальной информации, система не найдет новые уязвимости и не скажет о них. Стоит вспомнить громкую уязвимость конца 2021 года log4shell - обновления были выпущены в кратчайшие сроки, но несмотря на это, многие компании пострадали только из-за того, что не знали о наличии этой уязвимости в своей инфраструктуре.

7 of 14

Операционные системы

07 vulns.io

А что с данными? Западный IT-сегмент

Государственный источник

Программное обеспечение

Где же брать такие данные? Посмотрим сначала на западный рынок IT-решений.

На слайде представлены вендоры основных операционных систем, крупные производители ПО, а также правительственный источник. Все компании, представленные на слайде, публикуют уязвимости, найденные в своих продуктах, причем эти данные являются общедоступными, несмотря на то, что большая часть ПО является коммерческим. (слайд карта вендоров)

Стоит отметить Национальную базу уязвимостей, которую поддерживает национальный институт стандартов и технологий США. По большому счету данная база является агрегатором, собирает уязвимости различного ПО и оценивает их опасность по шкале 0-10. Данные NVD также являются общедоступными, содержат огромное количество уязвимостей, но для проведения точного аудита годятся мало. В основном из-за того, что они используют собственный формат данных, и в них не указаны правила, по которым можно определить, является ПО уязвимым или нет.

8 of 14

Операционные системы

08 vulns.io

А что с данными? Западный IT-сегмент

Государственный источник

Программное обеспечение

Стандарты описания уязвимостей

Говоря о формате данных – глядя на внушительную карту компаний, которые ведут свои базы уязвимостей, невольно возникает вопрос – все ли одинаково описывают свои уязвимости? К сожалению, далеко не все, хотя процессы стандартизации идут с 2000 годов. За последние 10-15 лет был проделан большой путь – появились стандарты, позволяющие описывать уязвимости для разного ПО, оценивать их опасность и находить их в инфраструктуре. Стандарт описания уязвимостей OVAL стал довольно популярным, и сегодня данные в OVAL-формате публикуют основные производители операционных систем.

9 of 14

Операционные системы

09 vulns.io

А что с данными? Западный IT-сегмент

Государственный источник

Программное обеспечение

Стандарты описания уязвимостей

10 of 14

10 vulns.io

А что с данными? Российский IT-сегмент

БДУ ФСТЭК

Дата создания: март 2015
Уязвимостей: 44 836
Вендоров ПО: 1 291
Российских ОС: 9
Российского ПО: 65

Государственный источник

Операционные системы

Вендоры ПО

Поговорим теперь о данных уязвимостей, которые можно найти у нас. Начать следует с основного источника данных об уязвимостях отечественного ПО – База данных угроз от ФСТЭК. Создана в марте 2015 года, на сегодняшний день содержит почти 45 тысяч записей об уязвимостях ПО более 1200 разных вендоров. Из них, 74 являются вендорами российского ПО, в том числе 9 разработчиков российских операционных систем. Суммарно, а базе ФСТЭК находится более 10000 уязвимостей, относящихся к отечественному ПО.

Следом идут упомянутые ранее разработчики российских операционных систем. Все эти компании занимаются поиском и устранением уязвимостей, что похвально, однако с публикацией данных ситуация несколько хуже. Во-первых, всего один из вендоров ОС с недавних пор открыто публикует данные об уязвимостях в OVAL формате. Это данные о системе RedOS компании Red Soft. Хочется отметить, что данная возможность появилась недавно в рамках технологического партнерства с нашей компанией, коллеги откликнулись на предложение организовать данные в стандартизированном формате, за что им большое спасибо.

Остальные вендоры, если и публикуют свои данные, то в намного более расслабленном режиме – обычно это выглядит как лента новостей или запись в блоге. Это очень сильно усложняет их обработку. Более того, не все вендоры публикуют данные открыто, хотя некоторые из них готовы предоставить данные по запросу или в случае приобретения сертификата на техническую поддержку.

11 of 14

11 vulns.io

А что с данными? Российский IT-сегмент

БДУ ФСТЭК

Дата создания: март 2015
Уязвимостей: 44 836
Вендоров ПО: 1 291
Российских ОС: 9
Российского ПО: 65

Государственный источник

Операционные системы

Вендоры ПО

12 of 14

12 vulns.io

Одной БДУ ФСТЭК не достаточно

Казалось бы, если есть БДУ ФСТЭК, то зачем просить данные у вендоров напрямую? Более того, при общении некоторые вендоры прямо рекомендовали обращаться за данными в базу ФСТЭК. Проблема в том, что данные в этой базе также имеют свой внутренний формат, в котором не указываются правила применимости той или иной уязвимости. Для сканирования использовать эти данные проблематично.

Есть и вторая причина. База ФСТЭКа по сути тоже собирает у себя уязвимости разных программ, данные могут добавляться с запаздыванием, и далеко не всегда представлена актуальная информация по устранению. А вот вендор, заинтересованный в том, чтобы его продукт был безопасным и не наносил ущерб, будет публиковать данные об уязвимостях и обновления безопасности сразу же по мере их появления.

13 of 14

13 vulns.io

К чему стремиться

Разработчикам российского ПО:

Публиковать данные об уязвимостях
Публиковать обновления безопасности
Придерживаться общепринятых стандартов описания уязвимостей

Регулятору:

Ввести общепринятый стандарт описания уязвимостей, при необходимости дополнить его
Обязать разработчиков отечественного ПО публиковать данные об уязвимостях, и делать это в соответствии со стандартом
Развивать программы «Bug Bounty», оказывать содействие компаниям-разработчикам в организации данных программ

Подводя итог, хочется обратить внимание разработчиков российского ПО на важность поиска уязвимостей в своих продуктах, и выпуска обновлений безопасности. Также не менее важно публиковать информацию о найденных уязвимостях, чтобы дать возможность своим клиентам оперативно их устранять.

Для того, чтобы этот процесс развивался, возможно потребуется участие регулятора:

- принять единый стандарт описания уязвимостей или разработать собственный

- обязать разработчиков ОС и ПО вести базы данных уязвимостей в соответствии с принятым стандартом

- Оказывать содействие компаниям при организации мероприятий Bug Bounty при условии публикаций найденных уязвимостей в базу ФСТЭК.

Подводя итог, хочется сказать, что текущая ситуация действительно обозначила новые реалии в вопросах информационной безопасности. Как вендор VM-системы, мы приспосабливаемся к этому, и хотим сделать отечественную инфраструктуру более защищенной, устойчивой к атакам. Для этого нужно вплотную заниматься вопросами поиска и устранения уязвимостей, параллельно развивая процессы управления уязвимостями. Нам следует использовать опыт стран, которые прошли долгий путь по выстраиванию этих процессов, и учесть во внимание проблемы, которые остались нерешенными – в основном с унификацией данных. В этом нам может помочь регулятор, путем развития и продвижения стандартов, методических рекомендаций и в целом способствовать развитию процесса управления уязвимостями.

14 of 14

a.nikonov@frodex.ru

+7(495) 967 65 19

frodex.ru

Техническая поддержка:

support@frodex.ru

офис

г.Уфа, ул. Пархоменко, 133/1, 2 этаж

Андрей Никонов

Старший инженер-программист