Управление уязвимостями в 2024 году: что изменилось и как перестроить процесс
Павел Попов, 17/04/24
Управление уязвимостями (Vulnerability Management) – важный аспект информационной безопасности. На первый взгляд, процесс стандартный везде: ведь злоумышленники, уязвимости программного обеспечения, неверно выстроенный патч-менеджмент есть повсюду. Однако в условиях всплеска числа кибератак, ухода зарубежных вендоров, импортозамещения ПО и обновления нормативно-правовой базы у процесса управления уязвимостями в России есть ряд важных особенностей. Разберем их и расскажем, как MaxPatrol VM [1] помогает выстраивать процесс управления уязвимостями в компаниях с учетом этих нюансов.
Автор: Павел Попов, лидер продуктовой практики MaxPatrol VM, Positive Technologies
Что нового в регулировании
С начала 2022 г. многие российские компании столкнулись [2] с беспрецедентным количеством кибератак на свою инфраструктуру. Первым полноценным документом в ответ на этот вызов стали "Критерии для принятия решения по обновлению критичного ПО, не относящегося к Open Source" [3] Национального координационного центра по компьютерным инцидентам (НКЦКИ).
Всего пять лет назад история о закладке в патче или в обновлении программного обеспечения могла показаться мифом. Сегодня же пользователи в России могут быть отключены от любого обновления или патча ПО по территориальному признаку. Поэтому НКЦКИ, в частности, отмечает [4] следующее:
приведенный в документе алгоритм, призванный помочь специалистам принять решение об обновлении, является рекомендацией;
применяя алгоритм, нужно обязательно учитывать контекст организации: рекомендуемые решения подходят не для всех случаев;
ПО перед обновлением в продуктивной среде должно быть проверено на корректную работоспособность в тестовом сегменте;
если возможно препятствовать эксплуатации уязвимости наложенными средствами защиты, производить обновление не рекомендуется;
если специалисты в состоянии проверить обновление ПО на наличие недекларированных возможностей, то следует принимать решение по результатам собственного анализа;
не рекомендуется применять этот алгоритм для обновления ПО в АСУ ТП и мобильных ОС.
Следующим важным документом стала "Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств" [5] Федеральной службы по техническому и экспортному контролю (ФСТЭК) России от 28 октября 2022 г. Главное отличие этой методологии – появление уникального идентификатора инфраструктуры, который указывает на частный уровень опасности уязвимостей, потому что у всех компаний есть неповторимые особенности, как у людей – отпечатки пальцев.
Еще один важный документ – "Руководство по организации процесса управления уязвимостями в органе (организации)" [6] издан ФСТЭК 17 мая 2023 г. Это уже полноценная методика, которая помогает рассчитать уровень опасности уязвимостей на основании предыдущего методического документа и определить срок и методы их устранения с учетом смежных процессов.
(Не)уязвимое ПО
Ключевой нюанс, отличающий процесс управления уязвимостями в России от VM в других странах, – массовое импортозамещение. В отличие от мировой практики российские разработчики редко публикуют информацию об уязвимостях, найденных в своем ПО. При этом многое в процессе управления уязвимостями приходится пересматривать "на живую". Например, в связи с тем, что злоумышленники часто угрожают корпорациям уничтожением инфраструктуры, последние не могут себе позволить ждать появления патча от вендора. В подобных случаях при появлении уязвимости на периметре нужно четко и быстро среагировать, принять компенсирующие меры.
Многие отечественные разработчики ПО после получения сертификата ФСТЭК России считают свой продукт неуязвимым. Однако и в таких системах могут быть найдены уязвимости нулевого дня (0-day) – нужно не только оперативно устранять их, но и публиковать информацию для клиентов. При использовании в продукте решений Open Source или общедоступного инструмента клиенты также должны получить инструкции по устранению проблем.
Некоторые виды ПО базируются на ядрах популярных Linux-систем, например Debian, CentOS, FreeBSD и RHEL. И тут возникает вопрос: что делать с их уязвимостями? Ведь операционная система переработана и уже отличается от той первоначальной, которую брали за основу. Можно просто взять известные уязвимости исходной ОС и начинать публиковать информацию о том, что есть и у ответвленного проекта (форка), но из-за изменений в системе не все недостатки будут совпадать.
Что учесть в 2024 году
Злоумышленники рано или поздно изучат уязвимые решения, обнаружат в них 0-day, а затем продадут информацию на черном рынке или будут использовать ее в целенаправленных атаках. Производители, которые не публикуют данные об уязвимостях и не выпускают обновления безопасности, усугубляют ситуацию.
Эксперты Positive Technologies рекомендуют вендорам сотрудничать с исследователями безопасности, на раннем этапе анализировать код своих продуктов с помощью специальных средств и выстроить процесс поиска уязвимых мест в ПО. После обнаружения уязвимостей необходимо разработать патч, присвоить им идентификаторы (согласно CVE [7] и (или) базе данных угроз ФСТЭК [8]) и опубликовать эту информацию. Если в конечном продукте используются решения Open Source, нужно сообщить о наличии или отсутствии в нем уязвимостей, чтобы клиенты смогли сосредоточиться на устранении реальных угроз.
Даже если у производителя есть сильная команда ИБ, это не гарантия защиты от взлома. Вендору нужно постоянно проверять свою защищенность, используя предназначенные для этого системы и привлекая внешних исследователей. В идеале каждый производитель ПО должен запускать программы багбаунти, чтобы тестировать свою инфраструктуру, процесс выпуска ПО и конечные продукты. Такие программы помогут обнаружить уязвимости еще до начала реальных атак и защитить клиентов.
[img]https://www.itsec.ru/hs-fs/hubfs/tg_image_3114192380.jpeg?width=2348&height=1078&name=tg_image_3114192380.jpeg[/img]
Рис. 1. Схема работы работы MaxPatrol VM
Можно использовать решения Open Source или простые сканеры уязвимостей, если устраивает экспертиза и точность детекта. Но в случае последних компания должна быть готова выстраивать процесс еще в нескольких системах. Мы же рекомендуем переходить к построению результативной безопасности и использовать системы Vulnerability Management, например MaxPatrol VM9. Продукт анализирует информацию об уязвимостях и выявляет трендовые, наиболее опасные для компании. Данные о них мы доставляем в MaxPatrol VM в течение 12 часов, что позволяет своевременно принять меры и защитить инфраструктуру компании.
Только 14% вендоров оперативно исправляют уязвимости, найденные исследователями безопасности
Эксперты Positive Technologies проанализировали собственный опыт взаимодействия с вендорами в области раскрытия уязвимостей. Так, в 2022–2023 гг. 57% вендоров оперативно отвечали исследователям компании, при этом только 14% всех производителей программного обеспечения выпускали обновления в оптимально короткие сроки.
Впервые обнаруженные недостатки безопасности, о которых производитель ПО не знает и для которых еще не существует исправлений, называются уязвимостями нулевого дня. Как только вендор узнает о таком недостатке, становится крайне важно своевременно выпустить исправление, поскольку задержки позволяют злоумышленникам все чаще эксплуатировать такие уязвимости в своих атаках.
Число обнаруженных уязвимостей постоянно растет: в 2023 г. их количество (28 902) превысило показатели предыдущих двух лет на 42% и 14% соответственно. Кроме этого, каждый взлом и утечка обходятся бизнесу все дороже: средняя стоимость утечки, по данным IBM, за последние три года выросла на 15%, достигнув $4,45 млн. В связи с этим особое значение для укрепления защиты приобретает построение доверительных и прозрачных отношений между поставщиками ПО и исследователями ИБ.
Промедление в ответственном раскрытии информации об уязвимостях чревато и ростом числа атак на цепочки поставок: за первые три квартала 2023 г. количество инцидентов, вызванных атаками подобного типа, выросло в два раза по сравнению с показателями за весь 2022 г.
Positive Technologies придерживается принципов координированного раскрытия в случае обнаружения уязвимостей в продуктах вендоров. При таком формате ответственного разглашения в процессе участвуют не только исследователи и производитель ПО, но и регуляторы, и организации, которые выступают посредниками во взаимодействии с поставщиками.
Основные проблемы при реализации принципов ответственного разглашения – недостаточная структурированность процессов взаимодействия вендоров с исследователями, а также непостоянство и задержки в отклике на сообщения о найденных уязвимостях. Специалисты Positive Technologies считают, что оптимальное время ответа вендора составляет от одного дня до недели: в такие сроки исследователям компании смогли ответить 57% вендоров.
Эксперты рекомендуют вендорам придерживаться профессионального подхода: следовать политике ответственного разглашения, доверять исследователям безопасности и поддерживать с ними активную коммуникацию, информируя о каналах связи. Кроме того, специалисты советуют производителям ПО выпускать обновления безопасности и сообщать об этом в кратчайшие сроки, достойным образом поощрять исследователей за нахождение уязвимостей, чтобы мотивировать их к продолжению эффективного сотрудничества.
Компаниям – пользователям ПО, в свою очередь, рекомендуется выстроить процесс управления уязвимостями, используя системы, предоставляющие информацию о трендовых уязвимостях (которые важно устранять в первую очередь); так, система MaxPatrol VM предоставляет такие данные в течение 12 часов.
https://www.ptsecurity.com/ru-ru/products/mp-vm/
https://www.ptsecurity.com/ru-ru/research/analytics/cybersecurity-threatscape-2022/
https://safe-surf.ru/upload/ALRT/ALRT-20220415.1.pdf
https://safe-surf.ru/specialists/news/678042/
https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/metodicheskij-dokument-ot-28-oktyabrya-2022-g-2
https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/metodicheskij-dokument-ot-17-maya-2023-g
https://cve.mitre.org/
https://bdu.fstec.ru/threat
https://www.ptsecurity.com/ru-ru/products/mp-vm/
www.itsec.ru