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

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

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

Улучшенное детектирование уязвимостей Windows и других продуктов Microsoft

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

Классический подход вендоров ИБ при расчете уязвимостей на конечных системах заключается в составлении базы соответствий «уязвимость → фикс». В качестве фикса обычно выступает или версия приложения, или идентификатор обновления. После этого сканер проверяет версию приложения или наличие установленного обновления в системе.

Компания Microsoft регулярно выпускает обновления (маркируемые как KB — от Knowledge Base) для своих операционных систем и программных продуктов. Период с 2015 по 2016 год стал периодом фундаментальных изменений в подходе к обновлениям. Вместо множества отдельных исправлений Microsoft начала объединять все обновления безопасности и улучшения (как новые, так и все предыдущие) в один ежемесячный пакет. Такие пакеты называют накопительными или кумулятивными. Процесс обновления для пользователей стал выглядеть проще: в любой момент времени выбираем последнее накопительное обновление и устанавливаем — оно точно закроет большинство или даже все уязвимости. С другой стороны, обновление, которое включает в себя множество изменений, может непредсказуемо сломать бизнес-процесс, в результате чего пользователю придется откатываться к предыдущей версии системы и либо принимать риски безопасности, либо искать другие способы митигации уязвимостей.

Для вендоров средств анализа защищенности такой переход добавил сложностей, так как теперь необходимо учитывать кумулятивность обновлений. Допустим, что условную январскую уязвимость CVE-2026-YYYY, которая есть только в одной версии продукта, закрывает вышедший в январе патч KB1. В феврале выходит накопительный патч KB2, учитывающий другие новые уязвимости. Соответственно, конкретную уязвимость CVE-2026-YYYY фактически закрывают уже два патча: KB1 и KB2. С каждым новым месяцем количество закрывающих обновлений увеличивается. Это требует от вендоров постоянной актуализации правил детектирования. С выходом каждого нового накопительного обновления соответствующие изменения должны оперативно отражаться в логике проверок. При этом пользователи должны своевременно обновлять базы правил в используемых средствах анализа. В противном случае правила детектирования быстро устаревают, что приводит к увеличению количества ложных срабатываний.

Мы нашли альтернативный способ для более надежной и простой атрибуции уязвимостей Windows. MaxPatrol VM анализирует версии ядра ОС, то есть мы практически полностью отказались от использования идентификаторов обновлений (KB) для расчета уязвимостей в поддерживаемых операционных системах Windows. Система сравнивает версии ядра операционной системы Windows. Мы выбрали файл ядра, так как его версия меняется при установке кумулятивного обновления.

Применение этого подхода стало возможным благодаря принципу атомарности (all or nothing) системы обновлений Windows. Атомарность гарантирует, что обновление либо устанавливается полностью и успешно, либо не устанавливается вовсе. Иными словами, можно говорить о том, что если изменилась версия файла, входящего в пакет обновлений, то обновление точно установлено.

Такое изменение позволило нам упростить описание модели уязвимости в секции условий существования и закрытия и не анализировать для каждой уязвимости полный список закрывающих KB. Также это ощутимо уменьшило время работы ядра MaxPatrol VM при расчете уязвимостей Windows, так как теперь для атрибуции уязвимостей учитывается не большой набор установленных KB, а только версия файла. Вместе с этим нам удалось уменьшить количество ложноположительных срабатываний, возникающих в различных ситуациях: когда обновление установлено, а в реестре нет об этом записи, когда есть проблемы с доступом к самому реестру, а также в случаях, когда запись об обновлении есть, но оно фактически не применено, так как система не была перезагружена. Расчет уязвимостей ускорился в среднем (в зависимости от сканируемой системы) на 6 секунд на актив, размер пакета с информацией об уязвимостях уменьшился на 20 МБ.

Детектирование уязвимостей Linux без выпущенного патча (Unpatched)

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

В самом простом случае процесс выпуска обновлений безопасности для пакетов ОС на базе Linux происходит следующим образом:

1. Производитель ПО, входящего в состав Linux-дистрибутива (ядра Linux, Bash, Nginx, OpenSSL и т. д.) узнает об обнаружении новой уязвимости.

2. Производитель ПО выпускает обновление безопасности и уведомляет об этом пользователей.

3. Мейнтейнеры Linux-дистрибутива, в котором была найдена проблема безопасности, оценивают ее, портируют патч из upstream в кодовую базу, на основе которой собирается пакет.

4. Мейнтейнеры тестируют исправление.

5. Мейнтейнеры выпускают новую исправленную версию и публикуют бюллетень безопасности.

У процесса выпуска исправлений безопасности для Linux-дистрибутивов и публикации бюллетеней безопасности есть особенности, которые производителю системы vulnerability management необходимо учитывать.

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

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

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

Для решения этой проблемы в качестве компромисса некоторые производители Linux-дистрибутивов публикуют информацию о так называемых Unpatched-уязвимостях, то есть уязвимостях, которые на данный момент не имеют исправления. После фактического исправления производители отдельно уведомляют пользователей.

Мы считаем, что если информация об уязвимости уже опубликована, средство анализа защищенности должно обнаруживать ее независимо от наличия исправления. Поэтому MaxPatrol VM уже предоставляет информацию об Unpatched-уязвимостях для Linux Debian. На момент публикации в Debian насчитывалось более 21 000 уязвимостей, для которых доступны патчи, и свыше 9 000 уязвимостей, для которых исправления пока не выпущены. В ближайшее время мы планируем расширить список поддерживаемых дистрибутивов: добавятся Red Hat Enterprise Linux, SUSE Linux Enterprise Server, а также openSUSE. Максимально ранняя осведомленность дает время на реализацию компенсирующих мер.

Детектирование ПО в состоянии End of Support

Нередко бывает, что установленное когда-то программное обеспечение перестает поддерживаться производителем, но все еще активно используется. Это означает не только то, что не выходят новые функции и не исправляются ошибки, но и то, что не закрываются уязвимости. Разработка эксплойтов для уязвимостей в популярных, но неподдерживаемых версиях ПО позволяет злоумышленнику потратить свои ресурсы один раз, а потом использовать эксплойт в атаках годами. История знает массу таких примеров: от громких и обошедших весь мир WannaCry и NotPetya, поразивших устаревшие версии Windows, до менее известных атак APT-группировок, использовавших уязвимости неподдерживаемых устройств Cisco для получения полного контроля.

Версии ПО, для которых производитель больше не предоставляет бесплатных обновлений (в том числе обновлений безопасности), относят к категории End of Support (EoS). Их важно выявлять в инфраструктуре, чтобы вовремя запланировать замену ПО, успеть в моменте смягчить риск эксплуатации и обнаружить возможные проблемы в процессе управления активами. Уже сейчас MaxPatrol VM показывает EoS как уязвимость.

Стоит отметить, что не всегда статус EoS является очевидным. Рассмотрим несколько ситуаций:

• Для некоторых версий программного обеспечения Microsoft может действовать отдельно оплачиваемая программа Extended Security Updates (ESU).

• Производители дистрибутивов на основе Linux довольно часто имеют LTS-версии систем (Long Term Support), которые широко используются. Но даже они имеют срок поддержки. Для подобных ситуаций многие вендоры предлагают отдельный вид поддержки устаревших систем. Хороший пример — Ubuntu и Expanded Security Maintenance (ESM).

• Бывает и такое, что производитель окончательно прекратил поддержку ПО, в том числе в виде отдельных услуг. Но поддержкой могут заниматься и другие компании. Так, TuxCare занимается поддержкой устаревших Linux-дистрибутивов в рамках Endless Lifecycle Support (ELS). ELS предоставляет исправления безопасности для ядра, критически важных пакетов (Apache, MySQL, PHP, OpenSSL, Glibc и др.) и пользовательских приложений.

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

Сканирование без доступа в систему

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

В отчетах самого популярного сетевого сканера с открытым исходным кодом Nmap это часто выглядит как unknown, ssl/unknown, http-proxy, tcpwrapped или самое неприятное и неочевидное — когда сервис атрибутируется только по номеру порта со знаком вопроса в конце (например, ssh?), подчеркивая недостаточность информации. Это является нормой для обособленного инструмента инвентаризации, но недопустимо в контексте сканера безопасности, поскольку дальнейшая работа с такими данными затруднительна.

Для решения задачи определения уязвимостей с помощью сетевого сканирования в MaxPatrol VM мы предлагаем использовать режим Pentest и сканирование веб-ресурсов внутренним компонентом WebEngine. В рамках сканирования найденные уязвимости можно разделить на две группы:

1. Подтвержденные уязвимости — уязвимости, выявленные с помощью «безопасной» проверки, которая фактически эксплуатирует уязвимость, но не несет дополнительных рисков нарушения безопасности сканируемого сервиса и программного обеспечения.

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

Улучшенный фингерпринтинг сервисов в модуле Pentest

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

Модуль Pentest базируется на надежных методах определения сервисов, которые мы называем Service Detection (SD). Они требуют глубокой эмуляции клиент-серверного взаимодействия, что позволяет эффективно справляться с определением прикладных протоколов. Они точно отвечают на вопрос, что это за протокол: HTTP, SSH, FTP. Однако часто на этом идентификация заканчивается.

Если сканер увидел протокол HTTP, возникает следующий логический вопрос: какое именно ПО работает поверх этого протокола. Это может быть система непрерывной интеграции Jenkins, трекер задач GitLab, панель управления маршрутизатором или кастомное веб-приложение. Для ответа на этот и не только этот вопрос недавно мы внедрили механизм фингерпринтинга сервисов. Это решение позволяет заглянуть глубже, понять природу работающего ПО и добиться максимальной информативности в комбинации с SD.

Ключевая особенность нашей реализации — разделение на два независимых метода, которые запускаются в разных сценариях. Это не универсальный механизм «для всего», а целевой инструмент, применяемый строго по ситуации:

1. Фингерпринтинг веб-сервисов (HTTP Fingerprinting). Запускается только если классический SDобнаружил HTTP или HTTPS Service. Его задача — уточнить, какое именно веб-приложение работает поверх протокола.

2. Универсальный фингерпринтинг сервисов (Generic Service Fingerprinting). Запускается только если сервис не определился вообще. Его задача — идентифицировать софт на портах, где классические методы не дали результата.

В отличие от глубокой эмуляции клиент-серверного взаимодействия, которая требует множества запросов, обмена пакетами и времени, фингерпринтинг работает быстро, так как отправляет один запрос и анализирует ответ на наличие специфичных признаков. Такими признаками могут быть текстовые баннеры, заголовки, последовательности байтов или даже хеши статических элементов интерфейса. Сканер отправляет заранее подготовленные запросы — «пробы», получает ответы и ищет совпадения во внутренней подготовленной базе. Пробы отправляются последовательно; после первого успешного совпадения дальнейшие пробы не отправляются. Это объясняет экономию запросов. При совпадении система извлекает версию программного обеспечения. Система определяет продукт и извлекает доступные сведения о нём, включая версию. Пользователь видит эти данные в карточке сервиса. В случае с Generic Fingerprinting при совпадении определяется сервис.

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

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

Еще одна важная особенность модуля Pentest — наша собственная база отпечатков. Большинство существующих решений для фингерпринтинга (например, открытые базы Nmap) ориентированы на глобальный рынок и западное программное обеспечение. В условиях импортозамещения и специфики российского сегмента сети этого недостаточно. Мы тщательно изучили особенности как внутреннего контура российских организаций, так и внешнего сетевого периметр, что позволило нам выявить пробелы в покрытии и создать собственную базу сигнатур, которая теперь стабильно расширяется самым популярным и востребованным софтом. Вот некоторые наиболее популярные продукты из топа Shodan, для которых было расширено покрытие.

Благодаря внедрению fingerprinting-механизма нам удалось закрыть множество слепых зон в инфраструктурном сегменте. Теперь сканер уверенно идентифицирует не только стандартные веб-серверы, но и специфичное ПО. В базе появились DevOps-инструменты: Jenkins, GitLab, Grafana, Docker API. Это позволяет сразу видеть системы непрерывной интеграции, которые часто становятся целью атак на цепочку поставок. Также добавлены базы данных и системные сервисы: ClickHouse, Tarantool, Neo4j, RabbitMQ, OpenVPN, HAProxy. При этом каждый новый отпечаток валидируется, чтобы минимизировать риск ошибки.

Внедрение механизма обеспечило нам увеличение покрытия определяемого ПО более чем в два раза. Дополнительный акцент сделан на устройствах безопасности и сетевом оборудовании. Мы добавили сигнатуры для веб-интерфейсов корпоративных маршрутизаторов и межсетевых экранов (Fortinet, MikroTik, Palo Alto). Это позволяет выявлять устройства периметра, которые часто становятся целью атак первого этапа, даже если они работают на нестандартных портах.

Кейс с Docker API заслуживает особого внимания. Часто администраторы оставляют порт Docker открытым без авторизации. Наш фингерпринтинг позволяет одним запросом решить две задачи: идентифицировать сервис по ответу API и сразу проверить доступность управления контейнерами. Это критическая уязвимость, и пользователь видит ее сразу, без дополнительного анализа. Порт не остается без сервиса, а сразу классифицируется как потенциально опасный ресурс.

Еще одна выполненная доработка — поддержка JARM (https://github.com/salesforce/jarm). JARM — это метод анализа на уровне TLS-рукопожатия, который формирует отпечаток сервиса на основе того, как сервер отвечает на набор специально сформированных TLS-запросов. В отличие от классического баннер-граббинга JARM не полагается на текстовые баннеры, версии ПО или заголовки протокола. Он анализирует поведение TLS-стека: поддерживаемые версии TLS, выбранные наборы шифров, расширения, ALPN и особенности ответа сервера.

Если два разных хоста имеют одинаковый JARM-отпечаток, с высокой долей вероятности они работают на одном и том же ПО, имеют схожую конфигурацию стека или принадлежат одной инфраструктуре. В продукте JARM встроен в существующий процесс SSL/TLS-обнаружения сервисов. После того как сканер определяет, что на транспортной точке доступен SSL/TLS, он автоматически выполняет расчет JARM-fingerprint. Полученный отпечаток сохраняется как дополнительный баннер транспортной точки и становится доступен последующим сервисным детектам.

Интеграция JARM с языком запросов PDQL открывает возможности для глубокого профилирования инфраструктуры. Пользователь сможет искать не только уязвимости или конкретные продукты, но и похожие хосты.

Например, обнаружив сервер с подозрительной TLS-конфигурацией, можно выполнить запрос по его JARM-отпечатку:

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

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

Добавленный механизм создаёт фундамент для нового класса технологий анализа инфраструктуры: от обнаружения продуктов без баннеров до поиска схожих активов и расследования инцидентов.

Важно понимать ограничения метода. Подход прост и чувствителен к системам обмана, хонепотам и мокам, которые специально мимикрируют под известные сервисы. Именно поэтому в нашей системе фингерпринтинг отрабатывает в последнюю очередь. Сначала запускается классический Service Detect, затем эвристики, и только, если они не дали результата, в дело вступает фингерпринтинг. Это позволяет сохранить высокую достоверность данных и избежать ложных срабатываний там, где возможна глубокая проверка.

MaxPatrol VM ориентирован на инфраструктурный анализ безопасности, поэтому мы тщательно фильтруем скоуп компонента. Мы не стремимся определить CMS сайта, это задача веб-сканеров. Наша цель — сетевое ПО. 

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

Улучшенное сканирование веб-приложений

Для сканирования веб-слоя в MaxPatrol VM используется модуль WebEngine. Этот модуль проверяет доступные точки входа, находит используемое ПО и его уязвимости, а также способен выявлять подтвержденные уязвимости с помощью безопасных проверок. Кроме того, WebEngine предоставляет общую информацию о безопасности веб-ресурса.

Как и в случае модуля Pentest, WebEngine позволяет выявлять как версионные (определяемые по версии ПО), так и подтвержденные уязвимости (эксплуатируемость уязвимости подтверждена в данной конкретной инсталляции безопасным способом). В настоящее время база модуля содержит сведения о более чем 69 000 уязвимостей, определяемых по версии, и почти 3500 безопасных проверок, из которых более 250 — результат работы наших экспертов (для более чем 20% из них нет публичного эксплойта). Также мы пополняем нашу базу знаниями об отечественном ПО: на текущий момент мы поддерживаем более 80 популярных программ, например Kaspersky Security Center, TrueConf, Passwork, MFlash.

Исследователи Positive Technologies регулярно обнаруживают уязвимости в различном программном обеспечении, после чего уведомляют об их наличии производителей. Среди найденных уязвимостей — уязвимость платформы Foswiki (BDU-2025-11654), уязвимость модуля настройки системы автоматизации АЗС «БУК TS-G» (BDU-2026-04518), уязвимости HR-платформы Websoft HCM (BDU-2025-12744 и BDU-2025-12748). Нам также важно донести эту информацию до наших клиентов, чтобы помочь им оперативно определить, подвержены ли они новым уязвимостям. Для этого мы внедрили механизм облачной доставки новых безопасных проверок в модуль WebEngine.

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

Стоит отметить, что модуль WebEngine может быть полезен и при сканировании веб-приложений собственной разработки. Например, он может выявлять SQL-инъекции, уязвимости типа File Upload, а также уязвимости, связанные с нарушением контроля доступа и небезопасной конфигурацией. Согласно отчетам разных аналитических команд (IBM X-Force Threat Intelligence Index 2024, Verizon DBIR 2025, ENISA Threat Landscape 2024, Solar 4RAYS, Positive Technologies) именно эти типы уязвимостей чаще всего использовались для получения контроля над веб-ресурсами в 2024 и 2025 годах.

Рекомендуемые патчи и поле How to fix

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

Для уязвимостей Windows поле Как исправить логически поделено на две части:

• В верхней части приведен алгоритм устранения уязвимости: указана дата, начиная с которой любое кумулятивное обновление закрывает уязвимость, а также механизм проверки через версию ядра. Также указаны имя ОС, релиз или Service Pack, идентификатор обновления (KB) и версия ядра, которая будет в системе после установки обновления.

• В нижней части приведены последние идентификаторы обновлений и версии ядер от текущего месяца, которые закрывают не только рассматриваемую уязвимость, но и остальные. Указанные здесь KB также есть и в разделе Патч.

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

На данный момент обновление коснулось таких продуктов, как Windows, AlmaLinux, Astra Linux, Debian, Rocky Linux, CentOS, «РЕД ОС», SberLinux, Ubuntu, Linux Mint, ALT Linux, Protego. Также расширенное описание поля Как исправить получили более 70 популярных программных продуктов, включая Google Chrome, .NET Framework, MS Exchange, Mozilla Firefox, «1C», 7-zip, Docker, Consul, MySQL, Nginx. Информация включает в себя имя ПО, уязвимые версии, последнюю уязвимую версию, а также ссылку для загрузки самой актуальной версии.

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

Сканирование внутренних приложений и опенсорсных компонентов

Начиная с версии 2.10 в MaxPatrol VM появились новые функции, которые заметно расширяют зону покрытия нашего продукта, позволяют выйти за рамки классической системы vulnerability management и взять на себя часть функций SCA-сканера (software composition analysis). Речь идет о возможности обнаружения уязвимостей в пакетах для Python.

Для качественного решения задачи нам нужно было научиться находить директории с пакетами Python в произвольном месте в системе, но с наименьшими затратами по ресурсам.

Благодаря этому улучшению наши клиенты повысят защищенность своей инфраструктуры: система предупредит об уязвимостях в библиотеках, которые используются во внутренних продуктах компании. Эта функция — важный дополнительный этап итогового сканирования рабочего окружения продуктов, поскольку позволяет обнаружить упущенные проблемы. Ведь уязвимость в одной популярной библиотеке ставит под удар все приложения, которые ее используют, и весь бизнес компании в целом, даже если собственный код не имеет уязвимостей или если производитель конкретного ПО не раскрывает эту информацию. MaxPatrol VM поддерживает расчет 4635 уязвимостей для 1147 пакетов Python и 165 уязвимостей для самого Python. В будущем мы планируем развивать эту функциональность и расширить ее для Node.js, Ruby и Golang.

Инструмент для написания собственных правил детектирования для установленного ПО

 Нередко встречаются ситуации, когда имеется программное обеспечение, которое необходимо обнаруживать, но используемое решение пока не умеет этого делать. Для решения подобных задач мы добавили механизм Audit Extension. Благодаря этому механизму через внутренний DSL появляется возможность узнать о наличии практически любого ПО, а также собрать набор его свойств и атрибутов. На скриншоте ниже показана реализация обнаружения клиента популярного мессенджера Telegram.

В секции extractors описана логика получения информации о наличии исполняемого файла мессенджера. Далее описан механизм получения версии Telegram с учетом очистки через регулярное выражение. Наконец, сущность Software заполняется необходимыми свойствами. Это дает пользователям возможность решать разные задачи — от обнаружения специфичного программного обеспечения до реализации требований внутренней политики ИБ, касающихся проверки настроек систем и сервисов.

Сначала найти — потом управлять

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

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

Оценить эти возможности лучше всего в ходе пилотного проекта. Он позволит сравнить качество детектирования MaxPatrol VM с уже используемыми решениями, выявить уязвимости, которые могли остаться незамеченными ранее и на практике убедиться, насколько повышение качества детектирования влияет на эффективность процесса управления уязвимостями.