Обзор рынка систем оценки уязвимостей

Резкий рост числа кибератак на российские организации за последние 3 года активно обсуждается на самых разных уровнях, однако атакующие не спешат менять основные применяемые тактики и методы, доказавшие свою эффективность и в целевых, и в массовых кибернападениях. Так, основными методами атак на отечественный бизнес по-прежнему остаются вредоносное ПО, использование методов социальной инженерии и эксплуатация уязвимостей. Уязвимость – это недостаток или ошибка в программном или аппаратном обеспечении, который может быть использован (проэксплуатирован) злоумышленниками для проведения кибератаки и нанесения ущерба интересам компании. Уязвимости, как правило, выявляются в операционных системах, системном и прикладном ПО, сетевых устройствах, средствах защиты, а устраняются за счет установки патчей – обновлений безопасности, которые выпускают разработчики уязвимого софта. Казалось бы, проблема эксплуатации уязвимостей должна легко решаться – вендорам достаточно всего лишь оперативно выпускать обновления, а организациям – устанавливать их. Однако, дьявол кроется в деталях:

Во-первых, атакующие зачастую обнаруживают уязвимости (так называемые уязвимости нулевого дня или Zero-Day) и начинают использовать их в атаках раньше, чем производители получают информацию об уязвимости и выпускают корректирующее обновление;
Во-вторых, даже если производители смогут немедленно выпустить обновление, то клиентам необходимо оперативно загрузить и установить его, но в корпоративных инфраструктурах с тысячами компьютеров бывает сложно быстро проверить, что устанавливаемое обновление не нарушит функциональность продукта (к сожалению, такое случается чаще, чем хотелось бы). Часто между выпуском обновления и первыми кибератаками проходит крайне мало времени: например, атакующие начали использовать эксплойт для уязвимости обхода аутентификации в продукте JetBrains TeamCity спустя всего 22 минуты после публикации кода для проверки наличия уязвимости;
В-третьих, в компаниях могут быть установлены тысячи продуктов от сотен различных производителей, поэтому ИТ-администраторам становится сложно контролировать актуальность версий всех используемых приложений;
В-четвертых, уже более двух лет существует проблема, характерная для российского бизнеса – ушедшие зарубежные вендоры не предоставляют отечественным компаниям лицензии, техническую поддержку и обновления для своего софта, что приводит либо к задержкам при получении обновлений, либо к полной невозможности их установки.

Кроме описанных сложностей, существуют и иные организационных нюансы. Например, для выявления, категорирования, учета и управления сведениями об уязвимостях еще в 1999 году американской организацией MITRE была запущена программа CVE (Common Vulnerabilities and Exposures), целью которой стало ведение единого общедоступного реестра уязвимостей и присвоение уникального CVE-идентификатора каждой уязвимости в формате CVE-YYYY-NNNNN (YYYY – год обнаружения уязвимости, NNNNN – порядковый номер). Количество учтенных в CVE-реестре уязвимостей растет нелинейно: так, по итогам 2001 года в реестре было всего 3 тысячи уязвимостей, в конце 2012 года – уже 53 тысячи, в 2019 году - почти 130 тысяч, а в незавершенном 2024 году – уже более 240 тысяч. Сведения об уязвимостях в реестр отправляют и присваивают им CVE-идентификаторы выделенные организации, которые входят в список авторизованных членов CNA (CVE Numbering Authorities), среди которых вендоры, поставщики облачных услуг, ИБ-компании, CERT-команды, провайдеры программ Bug Bounty и ассоциации разработчиков со всего мира. Число CNA-организаций также растет: еще в 2016 году это была всего пара десятков организации, в 2019 году – уже 100 организаций, а в 2024 – более 400 организаций. Уязвимости зачастую обнаруживают не только CNA-организации, но и независимые эксперты и ИБ-исследователи, которым нужно связаться с CNA и сообщить об обнаруженной проблеме по установленной форме для выделения CVE-идентификатора для найденной уязвимости. Однако, вместо этого забюрократизированного и не всегда результативного процесса, люди предпочитают просто написать о своем исследовании на странице в соцсети или на GitHub, откуда данные собирают и ИБ-компании, и злоумышленники.

Еще один реестр уязвимостей ведется американским институтом NIST с 2005 года – реестр NVD (National Vulnerability Database) получает данные из реестра CVE, затем специалисты NIST производят анализ уязвимости на основе уже имеющихся в CVE-реестре сведений и иной общедоступной информации, потом для уязвимости рассчитывается значение показателя CVSS (v4.0 и v3.1), присваиваются категории и идентификаторы CWE (Common Weakness Enumeration) и CPE (Common Product Enumeration), заполняется карточка уязвимости и, наконец, она публикуется в реестре NIST NVD.

К работе обоих реестров - и MITRE CVE, и NIST NVD – у ИБ-сообщества уже давно есть претензии:

Во-первых, бывают случаи, когда CNA-организации ошибаются при автоматизированной передаче данных в реестр CVE и заспамливают его;
Во-вторых, еще в 2017 году исследователи указывали на среднюю задержку в 7 дней между публикацией данных об уязвимостях в открытых источниках и их размещением в реестре NIST NVD, что предоставляет атакующим широкое окно возможностей для их эксплуатации. Более того, есть и вовсе поразительные задержки: например, информация об уязвимости с идентификатором CVE-2010-5326 была передана в MITRE еще в 2010 году, но запись о ней появилась лишь в 2016 году, при этом уязвимость активно использовалась в реальных кибератаках с 2013 по 2016 годы;
В-третьих, подсчеты исследователей показали, что по состоянию на апрель 2022 год в реестре CVE отсутствуют данные о более чем 100 тысячах уязвимостей, а в среднем реестр CVE не учитывает 33% всех известных уязвимостей. О данной проблеме известно давно – так, по некоторым подсчетам, в 2015 году в реестр MITRE CVE не были включены более 6 тысяч известных уязвимостей;
В-четвертых, в настоящий момент реестр и команда NIST NVD находятся в процессе трансформации, что вызывает озабоченность ИБ-сообщества, поскольку приводит к задержкам в анализе уязвимостей и заполнением реестра NVD. Так, на текущий момент наблюдается значительный разрыв в количестве полученных (более 25 тысяч) и проанализированных (всего 8 тысяч) командой NIST NVD уязвимостей за текущий год. Тем не менее, американское государственное агентство CISA в настоящий момент активно развивает свой проект Vulnrichment, в рамках которого частично компенсирует недостатки работы NIST NVD и самостоятельно выполняет обогащение и анализ данных об уязвимостях.

Кроме того, на российском ИБ-рынке есть и своя специфика в части учета уязвимостей: несмотря на то, что в списке CNA-организаций реестра MITRE CVE до сих пор присутствуют «Яндекс» и «Лаборатория Касперского», в настоящий момент участие в работе зарубежных команд и реестров уязвимостей для большинства отечественных производителей затруднено по понятным причинам. При этом в России с 2015 года функционирует суверенный реестр уязвимостей – БДУ ФСТЭК России (Банк данных угроз безопасности информации), который управляется совместными усилиями регулятора (ФСТЭК России) и профильного научного учреждения (ФАУ «ГНИИИ ПТЗИ ФСТЭК России»). На текущий момент в данном реестре находятся 60 тысяч уязвимостей, в том числе уникальных, которые были обнаружены в российском софте и не учтены в зарубежных реестрах уязвимостей. Особенностью российского рынка разработки ПО является повсеместное применение Open Source решений в рамках экстренного импортозамещения последних лет, однако управление уязвимостями в Open Source осложнено спецификой таких продуктов: использованием различных репозиториев для загрузки пакетов и обновлений, запутанными программными зависимостями, использованием множества сторонних компонентов и библиотек, которые кое-как поддерживаются энтузиастами или не обновляются вообще, а также сложностями с доскональной проверкой безопасности кода устанавливаемого ПО и с тонкой настройкой параметров безопасности Open Source решений.

Управление уязвимостями является одним из базовых процессов информационной безопасности в корпоративной среде. Несмотря на озвученные выше сложности, компаниям необходимо внедрять взаимосвязанные процессы управления активами, уязвимостями, конфигурациями, соответствием требованиям, киберинцидентами и непрерывно повышать их зрелость. Для внедрения процессов ИБ чрезвычайно важно не только руководствоваться требованиями бизнеса и законодательства, но и выбрать применимый и актуальный фреймворк. Для процесса управления уязвимостями можно руководствоваться, например, рекомендациями публикации NIST SP 800-40 «Guide to Enterprise Patch Management Planning» («Руководство по планированию корпоративного управления патчами», версия 4) или фреймворком «Управление уязвимостями» от CISA, а для оценки уровня зрелости процесса можно воспользоваться моделью от SANS. Рассмотрим вкратце документ от NIST актуальной четвертой версии (первая была выпущена еще в 2002 году), который в Приложении «A» содержит ссылки на перечень мер защиты из публикации NIST SP 800-53 rev.5 и является органичной частью известного фреймворка NIST Cybersecurity Framework.

Итак, в соответствии с видением авторов публикации NIST SP 800-40, корпоративное управление патчами (т.е. обновлениями безопасности) – это процесс определения, приоритизации, получения (приобретения), установки и проверки успешности установки патчей и обновлений в компании. Методами реагирования на киберриски эксплуатации уязвимостей могут быть классические опции риск-менеджмента:

Принятие: компания осознанно и согласованно принимает риск использования уязвимого ПО, либо полагаясь на имеющиеся меры защиты, либо оценивая потенциальные негативные последствия эксплуатации уязвимости как низкие.
Митигация (смягчение, минимизация): снижение риска за счет устранения уязвимостей (например, путем установки патчей или обновления ПО до версии, которая не содержит уязвимостей) и/или внедрения дополнительных мер защиты для снижения вероятности эксплуатации уязвимости (например, за счет использования межсетевых экранов и сегментирования сети для изоляции уязвимых систем и снижения поверхности атаки).
Передача (трансфер): снижение риска за счет разделения некоторых негативных последствий с другими лицами, например, путем использования киберстрахования или перехода к SaaS-провайдеру, который сам занимается установкой патчей.
Избежание: устранение риска за счет ликвидации поверхности атаки, например, путем деинсталляции уязвимого ПО, вывода активов с уязвимостями из эксплуатации, отключения уязвимого функционала на устройствах.

В документе NIST SP 800-40 подчеркивается, что по умолчанию компании принимают риск использования ПО, поскольку в любом софте злоумышленниками может быть внезапно обнаружена уязвимость, о которой не знает ни сам производитель, ни ИБ-компании, ни организация-пользователь – затем такие уязвимости эксплуатируются в атаках Zero-Day. Кроме того, оперативная установка патчей или обновление уязвимого ПО не всегда возможны ввиду недоступности обновления от производителя (выпуск обновления может затянуться на дни и недели), использования устаревшего или неподдерживаемого вендором ПО (обновление в этом случае может быть не выпущено никогда), необходимости протестировать обновление и дождаться «окна обслуживания» для его установки, необходимости приоритизировать порядок установки разных обновлений из-за ресурсных ограничений, необходимости установки только сертифицированных версий обновленного ПО (процесс сертификации может затянуться).

Описанный в публикации NIST SP 800-40 базовый жизненный цикл управления уязвимостями состоит из следующих этапов:

1) Учет активов: управление активами и учет установленных на них ОС, ПО, СЗИ, микропрограмм (прошивок), контроль используемых версий пакетов и библиотек, отслеживание новых уязвимостей в них.

2) Планирование реагирования на риск эксплуатации уязвимостей: оценка уровня риска эксплуатации уязвимости для активов компании, выбор метода реагирования на риск (принятие, митигация, передача, избежание) и способа его реализации.

3) Выполнение действий по реагированию на риск эксплуатации уязвимостей (в зависимости от выбранного метода реагирования):

3.a) Подготовка к реагированию: получение (приобретение), проверка и тестирование патчей; подготовка дополнительных защитных мер для уязвимого ПО; приобретение замены для уязвимых устаревших активов, которые не могут быть пропатчены (например, старые версии ОС или ПО).

3.b) Реализация реагирования: распространение и установка патча; покупка киберстраховки; внедрение дополнительных защитных мер; изменение конфигураций и состояния активов (например, перезагрузка).

3.c) Проверка успешности реализации реагирования: проверка корректности установки патча; проверка функционирования внедренных защитных мер; проверка того, что уязвимые активы больше не эксплуатируются.

3.d) Непрерывный мониторинг принятых мер: контроль того, что установленные обновления безопасности не будут удалены; защитные механизмы не будут отключены; срок обновления киберстраховки не будет пропущен; выведенный из эксплуатации актив не будет опять подключен к сети.

Авторы публикации NIST SP 800-40 подчеркивают, что важным аспектом жизненного цикла управления уязвимостями является организационная составляющая, например, разработка политик и процессов управления уязвимостями и изменениями, актуализация сопутствующей документации (например, инструкций по установке и проверке обновлений), журналирование действий, формирование отчетов. Кроме того, в п. 3.1 рассматриваемого документа указано, что одним из важнейших способов снижения числа потенциальных уязвимостей является защищенная настройка (харденинг) софта, а в п. 3.2 подчеркивается важность процесса управления активами, включая непрерывную инвентаризацию активов и учет их характеристик (например, тип платформы, версии ОС и ПО, свойства сетевого соединения актива, установленные на активе СЗИ, владелец и администратор актива, уровень критичности актива, зависимый от актива бизнес-процесс). В приложении «A» к рассматриваемой публикации также перечислены меры защиты из публикации NIST SP 800-53 (версия 5), которые применимы к процессам управления уязвимостями и обновлениями безопасности, такие как:

CM-2 «Baseline Configuration» (базовая конфигурация / конфигурирование эталонного образа);
CM-3 «Configuration Change Control» (контроль изменения конфигураций);
CM-8 «System Component Inventory» (инвентаризация системных компонентов);
SR-2 «Supply Chain Risk Management Plan» (план управления рисками цепочек поставок);
SR-3 «Supply Chain Controls and Processes» (меры защиты и процессы цепочек поставок).

Проблематика защищенной настройки ОС и ПО, формирования эталонных образов и базовых конфигураций (т.н. baseline'ов), разработки чек-листов кибербезопасности (бенчмарков), оценки соответствия настроек безопасности установленных ОС и ПО применимым требованиям и критериям давно известна. Так, первая версия документа NIST SP 800-70 «Guidelines for Checklist Users and Developers» («Руководство по чек-листам для пользователей и разработчиков») была выпущена еще в 2005 году, а на текущий момент актуальна уже четвертая версия этой публикации. Данная публикация описывает правила работы программы NIST по формированию чек-листов – National Checklist Program (NCP). Чек-лист безопасной конфигурации – это документ с описанием процедур по настройке параметров безопасности ОС или ПО в целях минимизации поверхности атаки, снижения рисков эксплуатации уязвимостей, снижения последствий от успешной реализации кибератак, выявления несанкционированных изменений в настройках систем. Программа NCP, поддерживаемая NIST, позволяет вендорам создать перечень и описание рекомендуемых настроек ОС и ПО, существенных с точки зрения обеспечения кибербезопасности, а пользователям – сравнить настройки своих систем с рекомендуемыми для выявления несоответствий, в том числе с использованием средств автоматизации. В настоящий момент общедоступный репозиторий NCP предлагает для загрузки почти 800 чек-листов кибербезопасности для различных ОС (в том числе мобильных), ПО, облачных сред, СУБД, сетевых устройств, СЗИ и т.д.

Отметим, что подход к управлению уязвимостями продолжает непрерывно эволюционировать: так, несколько лет назад была введена концепция проактивного риск-ориентированного управления уязвимостями (Risk-Based Vulnerability Management, RBVM), которая предполагает непрерывный динамический учет активов, скоринг рисков эксплуатации уязвимостей на основе свойств активов и уязвимостей (критичность актива, сетевая доступность актива, вероятность и последствия эксплуатации уязвимости и т.д.), интеграцию данных аналитики киберугроз (threat intelligence), эксплойтов (exploit intelligence) и уязвимостей (vulnerability intelligence), а также широкое использование методов автоматизации, машинного обучения и искусственного интеллекта для повышения эффективности процесса управления уязвимостями.

Резюмируя проанализированные документы, вызовы отрасли и современные подходы, можно сформулировать требования, которые, в дополнение к традиционным возможностям (сканирование, выявление уязвимостей, рекомендации по устранению, отчетность), логично будет предъявить к процессу и инструментам управления уязвимостями на сегодняшний день:

1) Агрегация: описанные выше недостатки работы реестров MITRE CVE и NIST NVD подталкивают к необходимости использования нескольких различных независимых источников информации об уязвимостях и способах их устранения, применяемых эксплойтах и наиболее популярных среди атакующих уязвимостях, опасных конфигурациях и способах их перенастройки. Важно помнить, что самая актуальная информация об опасных уязвимостях и готовые эксплойты для них зачастую появляются сначала на различных форумах, в соцсетях и мессенджерах, которые необходимо мониторить либо самостоятельно, либо доверить это поставщику услуг или производителю решения.

2) Обогащение: используемые уязвимости, уникальные эксплойты, использование недостатков конфигураций могут быть связаны с вредоносными кампаниями, определенным ВПО, кибергруппами и их характерными тактиками, техниками, процедурами (TTPs). По аналогии с данными киберразведки (индикаторами компрометации и атак), сведения об уязвимостях необходимо обогащать данными аналитики эксплойтов и уязвимостей (exploit intelligence, vulnerability intelligence), предварительно производя очистку и дедупликацию поступающей информации. В идеале нужно интегрировать инструменты управления уязвимостями с решениями класса TIP.

3) Приоритизация: как мы показали выше, количество уязвимостей непрерывно растет, поэтому всё чаще возникают ситуации, когда в крупных инфраструктурах обнаруживаются десятки тысяч непропатченных уязвимостей, которые невозможно обработать одновременно и оперативно. Вывод – требуется алгоритм приоритизации уязвимостей, чтобы сосредоточить усилия на наиболее критичных из них, установив исполнителям реалистичные сроки по применению выбранных мер обработки уязвимостей. Алгоритм приоритизации может быть основан на использовании систем и метрик CVSS (Common Vulnerability Scoring System, предпочтительно использовать наиболее современную CVSS v.4.0), EPSS (Exploit Prediction Scoring System, использует методы машинного обучения для оценки вероятности эксплуатации уязвимости в реальных атаках), CISA KEV (Known Exploited Vulnerabilities, перечень наиболее часто эксплуатируемых уязвимостей по данным агентства CISA), CISA SSVC (Stakeholder-Specific Vulnerability Categorization, система категорирования уязвимостей на основе оценки уровня негативного воздействия на бизнес). Кроме того, ФСТЭК России в 2022 году выпустил методический документ «Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств», в котором описан алгоритм определения уровня критичности уязвимостей.

4) Интеграция инструмента управления уязвимостями с системами управления активами (CMDB, ITAM) позволит более качественно приоритизировать уязвимости за счет получения самой актуальной информации о защищаемой инфраструктуре. Интеграция с системами управления киберинцидентами (SIEM, SOAR, XDR) позволит выявлять эксплуатацию уязвимостей в кибератаках, превентивно внедрять компенсирующие меры (например, централизованно перенастраивать СЗИ с помощью SOAR) и приоритизировать киберинциденты (например, если на атакуемом активе присутствует неустраненная уязвимость). Интеграция с системами управления заявками и задачами (Service Desk) позволит выстроить процесс коммуникации со смежными подразделениями (прежде всего, с ИТ-специалистами и риск-менеджерами) для повышения оперативности обработки уязвимостей.

5) Управление конфигурациями и соответствием требованиям по безопасности (чек-листам) позволит проактивно устранять потенциальные слабые места активов, уменьшить поверхность атаки, снизить риск и последствия эксплуатации уязвимостей. Следует также отметить, что в некоторых случаях вендоры в качестве временной меры до выпуска и установки обновления безопасности предлагают некий workaround, который может заключаться в перенастройке параметров уязвимого компонента (например, для ОС Microsoft Windows это может быть изменение параметров реестра), и централизованное управление конфигурациями поможет оперативно применить такие настройки. В случае же отсутствия возможности получить обновление, что характерно для продуктов ушедших зарубежных вендоров, такой workaround может быть едва ли не единственным эффективным способом снизить риск эксплуатации уязвимости для российских компаний.

6) Применение методов машинного обучения и систем искусственного интеллекта поможет разобраться в огромном потоке информации об уязвимостях и способах их устранения, эксплойтах, активах, TTPs атакующих и киберинцидентах, связанных с эксплуатацией уязвимостей. Методы активного и пассивного сканирования инфраструктуры, API-интеграции с различными СЗИ и сервисами аналитики уязвимостей, данные от endpoint-агентов генерируют поток событий, которые необходимо нормализовать и скоррелировать для эффективного управления уязвимостями и смежными процессами ИБ.

Первые инструменты для сканирования сетей на наличие уязвимостей появились еще в середине 90-х годов, например, сканер Security Administrator Tool for Analyzing Networks (SATAN) был разработан в 1995 году как бесплатный инструмент для поиска уязвимостей и небезопасных конфигураций Linux-систем, а первые версии существующих и сейчас сканеров Nmap и Nessus были выпущены в 1997 и 1998 годах соответственно. Сейчас, по прошествии почти 30 лет, на рынке ИБ присутствует множество классов решений, которые в той или иной мере работают с уязвимостями. Данные продукты могут быть установлены on-prem или в облачной инфраструктуре, могут приобретаться по подписке (как сервис) и использовать агентный или безагентный формат работы, а также позволяют:

1) Выполнять активное сетевое сканирование для инвентаризации активов и выявления уязвимостей. Сканирование может быть неаутентифицированным (без использования учетных записей для удаленного подключения) или аутентифицированным (с использованием учетных записей, как правило, обладающих административными полномочиями).

2) Получать информацию (параметры устройства, версии ПО, настройки конфигурации) от установленных на конечных точках агентов.

3) Выполнять пассивное сетевое сканирование за счет анализа сетевого трафика (по аналогии с NTA или IDS) с последующим обнаружением активов и признаков использования определенного ПО.

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

5) Использовать интеграции с внешними и внутренними сервисами для получения обогащающей и контекстуализирующей информации об уязвимостях и способах их устранения, применяемых в реальных кибератаках эксплойтах, популярных среди атакующих уязвимостях и недостатках конфигураций, иной релевантной информации.

Компания Гартнер выделяет следующие категории решений для управления уязвимостями:

1) Vulnerability Assessment (инструменты оценки уязвимостей) обладают функционалом выявления, категоризации, приоритизации уязвимостей и управления их обработкой. Основное предназначение данных типов решений – оценка уязвимостей и конфигураций безопасности систем для выявления и снижения соответствующих рисков, а также оценка их соответствия разнообразным стандартам и baseline'ам. В данной категории представлены такие зарубежные решения, как Qualys Vulnerability Management Detection & Response, Cisco Vulnerability Management, Microsoft Defender Vulnerability Management, продукты компаний Tenable (Nessus, Tenable Security Center, Tenable Vulnerability Management) и Rapid7 (InsightVM, Nexpose), а также ряд других. В эту категорию можно также условно отнести бесплатный инструмент OpenVAS и сканер Nmap с NSE-скриптами.

2) External Attack Surface Management (EASM, инструменты управления внешней поверхностью атак) позволяют в непрерывном режиме выявлять доступные для атак из Интернет корпоративные системы, небезопасно настроенные элементы облачных инфраструктур, иные доступные для эксплуатации сведения (например, учетные данные пользователей или уязвимости в коде используемых компанией продуктов, которые могут быть использованы атакующими). В данной категории представлены такие зарубежные решения, как Microsoft Defender External Attack Surface Management, CrowdStrike Falcon Surface, Palo Alto Networks Cortex Xpanse, Mandiant Attack Surface Management, Group-IB Attack Surface Management и другие.

3) Cyber Asset Attack Surface Management (CAASM, инструменты управления поверхностью атак на информационные активы) предоставляют компаниям возможность обнаружения внешних и внутренних информационных активов, консолидации информации и поиска по собранным данным, выявления уязвимостей и недостатков мер защиты – всё это достигается, как правило, за счет API-интеграций с уже установленными в инфраструктуре решениями. В данной категории представлены такие зарубежные решения, как Qualys CyberSecurity Asset Management, Rapid7 Command Platform, Lansweeper, Axonius Platform, JupiterOne и прочие.

На российском рынке ИБ также присутствует ряд известных игроков, предлагающих решения для управления уязвимостями. Так, сканер уязвимостей XSpider от компании Positive Technologies был выпущен в 2002 году, а самая первая freeware-версия этого инструмента появилась еще раньше – в 1999 году. На сегодняшний день компания выпускает также продукт MaxPatrol 8 и флагманскую платформу управления уязвимостями – MaxPatrol VM. Еще одна известная компания – Лаборатория Касперского – включила в свой продукт Kaspersky Security Center инструменты для контроля и обновления установленного ПО, поиска и устранения уязвимостей на устройствах под управлением ОС Microsoft Windows. На российском рынке также присутствуют другие игроки, предлагающие решения класса Vulnerability Assessment: АЛТЭКС-СОФТ (продукт «RedCheck»), НПО «Эшелон» (продукт «Сканер-ВС»), Фродекс (продукт «Vulns.io Enterprise VM»), ЦБИ-сервис (продукт «Ревизор Сети»), R-Vision (продукт «R-Vision VM»), Security Vision (продукт «Security Vision VM»), а также ряд других. Для управления поверхностью атак отечественный рынок предлагает следующие решения класса EASM: BI.ZONE Continuous Penetration Testing, F.A.C.C.T. Attack Surface Management, Future Crew Cicada8, Start X EASM, Vulnspace Metascan, Сайбер ОК «СКИПА». Для управления конфигурациями есть, например, российские решения от компаний Газинформсервис (продукт «Efros Config Inspector«) и Spacebit (продукт«X-Config»). Кроме того, к продуктам для управления уязвимостями можно отнести и решения классов SAST, DAST, IAST для статического, динамического, интерактивного анализа безопасности приложений соответственно, а также продукты классов SCA (Software Composition Analysis, анализ состава ПО), OSA (Open Source Analysis, анализ компонентов с открытым исходным кодом) и API ST (API Security Testing, тестирование безопасности API), однако они находятся за рамками данного обзора.

В заключение можно констатировать: несмотря на то, что управление уязвимостями – это один из базовых процессов ИБ, для которого в течение последних 30 лет уже накоплен мировой опыт и сформировались лучшие практики, тема управления уязвимостями и конфигурациями всё так же является достаточно глубокой и комплексной. Современные технологии – искусственный интеллект, машинное обучение, облака, контейнеризация и практики CI/CD – приводят к непрерывной эволюции ПО и увеличению объема кодовой базы, соответствующим образом растет и число уязвимостей. Организационные сложности (на примере реестров MITRE CVE и NIST NVD), разрозненность подходов к учету уязвимостей, применение злоумышленниками всё более продвинутых инструментов обнаружения уязвимостей и разработки эксплойтов лишь подчеркивают необходимость выстраивания всеобъемлющего и зрелого процесса управления уязвимостями в самых разных компаниях. Вызовы, связанные с внезапным уходом зарубежных вендоров и экстренным импортозамещением, по-прежнему актуальны и требуют инновационных подходов даже к базовым процессам ИБ, включая управление уязвимостями и конфигурациями новых отечественных разработок и ушедших западных продуктов. И именно поэтому приятно отметить, что на российском рынке ИБ появляется всё больше интересных игроков, которые предлагают решения для самых разных аспектов процесса управления уязвимостями.