Архив метки: FSTEC

На сайте CISA 22 сентября опубликовали документ "Программа CVE: формирование фреймворка эры качества"

На сайте CISA 22 сентября опубликовали документ Программа CVE: формирование фреймворка эры качестваНа сайте CISA 22 сентября опубликовали документ Программа CVE: формирование фреймворка эры качества

На сайте CISA 22 сентября опубликовали документ "Программа CVE: формирование фреймворка эры качества". В оригинале "CVE Program: Establishing a Quality Era Framework". Основная проблема, которую они там фиксируют: CVE Program быстро масштабируется, вместе с объёмом уязвимостей растёт нагрузка на процессы публикации, проверки и сопровождения CVE-записей.

По состоянию на 18 сентября 2026 года опубликовано более 67 тыс. новых CVE. По данным NVD, число CVE, поступивших на обработку, выросло на 263% в 2020-2025 годах. За первые три месяца 2026 года на обработку поступило на треть больше CVE, чем за тот же период 2025 года.

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

Руководство CISA выделяет четыре направления работы:

🔹 управление CVE Program;
🔹 участие представителей экосистемы - CNA, Roots, CNA-LR, исследователи, вендоры, поставщики инструментов и государственные организации;
🔹 инфраструктура данных - API, схемы, библиотеки проверки и CVE Org;
🔹 качество записей CVE - полнота, точность, своевременность и практическая применимость данных.

Для этих направлений определены показатели качества (на иллюстрации) - от времени принятия управленческих решений и надёжности API до доли записей CVE, соответствующих установленным критериям качества, и количества исправлений после публикации (или скорости внесения исправлений? 🤔 Имхо, тут неоднозначно: "Rate of corrections/updates needed post-publication").

"Эпоха качества требует согласованного развития по четырём направлениям: управление программой CVE, участие представителей экосистемы, инфраструктура данных и содержание записей CVE.

🔻 Улучшение содержания записей CVE зависит от чётких требований к данным, эффективных инструментов и активного участия CNA.
🔻 Развитие инфраструктуры данных требует постоянных инвестиций, защищённых и масштабируемых систем, а также обратной связи от пользователей, которые используют эти данные.
🔻 Расширение участия в экосистеме зависит от широкого представительства технологий, отраслей, регионов и сообществ, которые обслуживает программа CVE.
🔻 Совершенствование управления программой зависит от прозрачного управления, дальнейшего организационного развития, совместного участия, эффективности и способности оперативно реагировать на потребности мирового сообщества, занимающегося управлением уязвимостями."

Этот документ задаёт рамку для следующего этапа развития CVE Program (читай: по большей части вода-водичка, правильные общие слова и благие намерения без какой-либо конкретики 😉). Описания конкретных изменений обещают выложить в ближайшие месяцы: "в этой серии публикаций будут описаны текущие и планируемые улучшения ключевых компонентов инфраструктуры, обеспечивающих работу программы CVE".

Коллегам из ФСТЭК тоже стоит к этой движухе присмотреться и, возможно, что-то перенять для развития БДУ.

На конференции IT Elements эксперты компании Инфосистемы Джет представили "Фреймворк антихрупкой ИТ-архитектуры", учитывающий состояние процесса Управления Уязвимостями в организации

На конференции IT Elements эксперты компании Инфосистемы Джет представили Фреймворк антихрупкой ИТ-архитектуры, учитывающий состояние процесса Управления Уязвимостями в организации

На конференции IT Elements эксперты компании Инфосистемы Джет представили "Фреймворк антихрупкой ИТ-архитектуры", учитывающий состояние процесса Управления Уязвимостями в организации. Фреймворк включает в себя 7 стратегий по четырём направлениям:

🔹 Подготовка к вторжению - 1. Системное развитие и контроль, 2. Подготовка и прогнозирование.
🔹 Слева от вторжения - 3. Вовлечение и нападение, 4. Защита, замедление, сдерживание.
🔹 Справа от вторжения - 5. Обнаружение и реагирование.
🔹 После вторжения - 6. Восстановление, 7. Адаптация и перестройка.

Эти стратегии раскладываются в 33 домена, которые, в свою очередь, раскладываются в 390 практик.

Чтобы замерить индекс антихрупкости для своей организации, можно воспользоваться специальным интерактивным опросником. Индекс оценивает способность компании пережить кибератаку, продолжать работу в её условиях и восстановиться после неё. По итогам заполнения опросника получаем индекс от 0 до 100%, разбор по направлениям защиты и сравнение с другими участниками. Отраслевой уровень обновляется автоматически по мере накопления ответов респондентов. Индекс рассчитывается по открытой методике. Опросник должен заполнять CISO. Вопросы однотипны, варианты ответов: "Да", "Частично", "Нет", "Неприменимо", "Не знаю".

Теперь пройдёмся по 13 практикам, которые непосредственно связаны с Управлением Уязвимостями. Они находятся в разделе Слева от вторжения -> 4. Защита, замедление, сдерживание -> 4.4 Непрерывная работа с уязвимостями.

📄 Формализация процесса, ответственные за устранение и сроки устранения

4.4-1 Регламентирован и реализуется процесс управления уязвимостями, определяющий порядок их выявления, оценки критичности, планирования и контроля устранения. Определяются ответственные за устранение уязвимостей и реализацию исправлений, а также целевые сроки, согласованные службами ИБ и ИТ

В опроснике: 49. Регламентирован и реализуется процесс управления уязвимостями. Определены ответственные за устранение уязвимостей и реализацию исправлений, а также целевые сроки, согласованные службами ИБ и ИТ

📄 Задачи на сканирование

4.4-2 Определен перечень, приоритеты и сроки сканирования каждого актива/типов активов. В область сканирования включены все активы, обеспечивающие критически значимые процессы организации

В опроснике нет.

📰 Отслеживание информации об уязвимостях

4.4-3 Определены источники информации об уязвимостях (например, БДУ ФСТЭК России, уведомления от регуляторов, сайты производителей ПО, каналы СМИ и др.). Информация из этих источников систематически анализируется на предмет применимости к активам организации, выявленные релевантные уязвимости регистрируются

В опроснике нет.

🚨 Экстренная обработка уязвимостей

4.4-4 Документирована и реализуется процедура экстренной обработки критических уязвимостей, определяющая порядок оповещения ИБ и ИТ, экстренной оценки применимости уязвимости, реализации временных защитных мер и координации действий с процессом кризисного реагирования.

В опроснике: 50. Документирована и реализуется процедура экстренной обработки критических уязвимостей, определяющая порядок оповещения ИБ и ИТ, экстренной оценки применимости уязвимости, реализации временных защитных мер и координации действий с процессом кризисного реагирования.

🔎 Сканирование на наличие уязвимостей

4.4-5 Функционирует процесс регулярного автоматизированного поиска уязвимостей. Поиск выполняется автоматизированными средствами, использующими актуальные базы данных (сканеры уязвимостей).

В опроснике: 51. Функционирует процесс регулярного автоматизированного поиска уязвимостей. Поиск выполняется автоматизированными средствами, использующими актуальные базы данных.

💿 Базовые образы

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

В опроснике нет.

⚖️ Продвинутая приоритизация уязвимостей

4.4-7 Приоритизация устранения уязвимостей выполняется по риск-ориентированным критериям, включая критичность актива, последствия эксплуатации, наличие доступных способов эксплуатации и техническую оценку уязвимости. Приоритеты используются для определения сроков устранения и контроля выполнения.

В опроснике: 52. Приоритизация устранения уязвимостей выполняется по риск-ориентированным критериям. Приоритеты используются для определения сроков устранения и контроля выполнения.

🔐 Сканирование с аутентификацией

4.4-8 Для обнаружения уязвимостей применяется аутентифицированное сканирование узлов, при котором средство сканирования получает контролируемый доступ к системе для более точного выявления уязвимых компонентов и конфигураций.

В опроснике нет.

🔗 Интеграция с GRC

4.4-9 Данные об уязвимостях автоматически синхронизируются с реестром рисков или системой управления рисками (GRC-системой). Изменение статуса уязвимости приводит к пересчету параметров риска и созданию или обновлению карточки риска.

В опроснике нет.

🎫 Интеграция с Task Tracker

4.4-10 Реализована интеграция инструментов сканирования уязвимостей с системой управления задачами. Задачи на устранение уязвимостей формируются автоматически, приоритет задач определяется критичностью уязвимости и значимостью актива.

В опроснике нет.

↪️ Компенсирующие меры

4.4-11 Для уязвимостей, устранение которых невозможно или небезопасно, определяется и применяется набор компенсирующих мер, выбор которых документируется и привязывается к конкретной уязвимости и активу.

В опроснике нет.

💭 План снижения риска

4.4-12 Для унаследованных систем, которые невозможно привести к актуальному уровню безопасности, разработаны и выполняются планы снижения риска. Планы определяют целевое состояние системы (вывод из эксплуатации или замена) и устанавливают временные меры защиты на период ее эксплуатации.

В опроснике нет.

⏱️ Отслеживание сроков устранения

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

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

В целом, довольно толковый набор практик. 👍 Единственное, не очень понятно, почему практик больше, чем вопросов в опроснике. Возможно, отобрали самое важное, а может, опросник будут расширять. 🤷‍♂️

Про уязвимость Remote Code Execution - TrueConf Server (CVE-2026-72529, CVE-2026-72530)

Про уязвимость Remote Code Execution - TrueConf Server (CVE-2026-72529, CVE-2026-72530)

Про уязвимость Remote Code Execution - TrueConf Server (CVE-2026-72529, CVE-2026-72530). TrueConf Server - российский on-premise корпоративный мессенджер и платформа для UltraHD видеоконференций. Рассматриваемая цепочка состоит из двух критических уязвимостей. Первая уязвимость CVE-2026-72529, вызванная отсутствием аутентификации критически важной функции (CWE-306), позволяет неаутентифицированному удалённому злоумышленнику с сетевым доступом к TCP-порту 4307 (открыт по умолчанию, согласно документации TrueConf) обратиться к недокументированной функции TrueConf Server и выполнить произвольный скрипт внутри изолированной среды ("песочницы"), в которой недоступны потенциально опасные библиотеки. Вторая уязвимость CVE-2026-72530 позволяет злоумышленнику осуществить инъекцию кода (CWE-94), выйти за пределы изолированной среды и выполнить произвольный код на ОС хоста с максимальными привилегиями. В том числе злоумышленник может удалить из журналов событий TrueConf записи, связанные с использованием эксплоита.

⚙️ Исправления для уязвимостей были выпущены 18 июня 2026 года. Уязвимыми являются версии 5.3.x ниже 5.3.9, 5.4.x ниже 5.4.9, 5.5.x ниже 5.5.5, а также ветки 5.2 и ниже (для обновления старых версий требуется обращение в техподдержку). Перерегистрация сервера при обновлении в рамках веток 5.3-5.5 не требуется, однако перед установкой вендор настоятельно рекомендует сделать бэкап. Если немедленное обновление невозможно, рекомендуется ограничить доступ к TCP-порту 4307 доверенными сетями.

👾 Эксперты Kaspersky ICS CERT раскрыли детали эксплуатации цепочки уязвимостей в посте, опубликованном 12 августа. Атаки с эксплуатацией уязвимостей CVE-2026-72529 и CVE-2026-72530 проводились на российские организации с июля 2026 года. В ходе атак злоумышленники получали сетевой доступ к TrueConf Server через порт 4307, с помощью CVE-2026-72529 выполняли скрипт в песочнице, а затем использовали CVE-2026-72530 для выхода из неё и выполнения кода с правами NT AUTHORITY\SYSTEM. Это позволяло им заменить один из файлов сервера TrueConf собственным веб-шеллом. В дальнейшем этот веб-шелл использовался для сбора информации об ИТ-инфраструктуре атакуемой организации, получения привилегированного доступа к базе данных TrueConf Server и подмены легитимных установщиков TrueConf Client вредоносной версией, содержащей малварь PhantomCore. После этого пользователи получали сообщение о необходимости загрузить новую (вредоносную) версию клиента TrueConf.

ВАЖНО: даже если в вашей организации не используется TrueConf, ваши сотрудники могли подключаться к взломанным серверам TrueConf ваших подрядчиков и контрагентов для участия в совместных онлайн-конференциях и, как следствие, могли установить вредоносную версию клиента на свои рабочие десктопы!

Малварь PhantomCore, характерная для APT-группировки Head Mare, автоматически загружается после старта системы и позволяет выполнять произвольные команды, фактически предоставляя злоумышленникам полный контроль над заражённым хостом. Также исследователи Kaspersky сообщали об использовании в атаках нового бэкдора, который они назвали PhantomGraph. Обе уязвимости (CVE-2026-72529 и CVE-2026-72530) были добавлены в CISA KEV 20 августа 2026 года.

🛠 Публичный эксплойт для CVE-2026-72530 был опубликован на GitHub 26 августа. Для полной цепочки уязвимостей CVE-2026-72529 и CVE-2026-72530 публичного эксплойта пока не наблюдается (несмотря на соответствующие флаги в БДУ ФСТЭК).

🌐 TrueConf Server широко используется в России и за рубежом, в том числе государственными учреждениями, финансовыми, промышленными, медицинскими и образовательными организациями.

Коллеги из команды Vulners обновили утилиту Getsploit

Коллеги из команды Vulners обновили утилиту Getsploit

Коллеги из команды Vulners обновили утилиту Getsploit. Утилита позволяет искать публичные эксплоиты в базе данных Vulners.com. При этом поддерживается как онлайн-режим работы (поисковые запросы выполняются на сервере Vulners), так и полностью офлайн-режим (данные об эксплоитах из Vulners складываются в локальный индекс SQLite FTS5, по которому выполняется дальнейший поиск). Второй вариант, как мне кажется, наиболее интересный и выгодный. 😉 Скачивание данных выполняется одной командой getsploit --update, итоговый размер базы ~1,7 ГБ.

Дальше можно искать эксплоиты локально, по CVE или полнотекстово:

$ getsploit --local CVE-2024-3094
$ getsploit --local "wordpress 4.7 remote code execution"

В результате получаете информацию об эксплоитах в формате: ID, Title и URL на сайте Vulners.

Если использовать ключик "--mirror", то тексты найденных эксплоитов будут сохраняться в отдельные файлики. Это работает со всеми базами эксплоитов Vulners кроме githubexploit и gitee.

Зачем вообще искать эксплоиты? Это может быть весьма полезно для обогащения данных по уязвимостям в вашем VM-решении и, соответственно, для более адекватной приоритизации. Если вы приоритизируете уязвимости по методике ФСТЭК, то информация об эксплоитах будет нужна для определения показателя Iat. Ну и для редтимовской работы тоже может быть весьма полезно отслеживать появление новых инструментов эксплуатации. 😉

Что почём? Один запрос на обновление getsploit расходует 10 кредитов. Согласно прайс-листу, в бесплатном плане сейчас 100 кредитов в месяц. Соответственно, если обновлять данные по эксплоитам раз в 3 дня, то можно пользоваться вообще бесплатно. 🆓 За $600 можно получить 600 кредитов в месяц, и этого хватит, чтобы обновлять getsploit ~ дважды в день.

В двух словах о Security Vision Vulnerability Scanner

В двух словах о Security Vision Vulnerability Scanner

В двух словах о Security Vision Vulnerability Scanner. Коллеги из Security Vision запустили видео-рубрику "В двух словах", в рамках которой рассказывают о ключевых возможностях продуктов компании, о том, как они защищают бизнес и помогают ему развиваться. В первом выпуске Альбина Михалёва, менеджер по работе с партнёрами, рассказала о Security Vision Vulnerability Scanner (VS).

Видео, естественно, высокоуровневое и маркетинговое. Но для понимания позиционирования решения компании - весьма любопытное. 😉

Security Vision Vulnerability Scanner - это инструмент для поиска уязвимостей в вашей инфраструктуре, использующий собственный движок. Он проверяет: операционные системы, прикладное ПО, сетевые устройства, базы данных, контейнеры. Сканирование можно проводить с агентом или без него. Поддерживаются российские ОС (Астра Линукс, Альт Линукс, РЕД ОС). Работает на основе ведущих баз уязвимостей (ФСТЭК, NVD и других).

🔑 5 ключевых особенностей продукта

1. Продвинутые режимы сканирования. Белый ящик для аудита защищённости. Чёрный ящик (пентест) с более чем 80 экспертных скриптов для проверки эксплуатации уязвимостей, подбора слабых паролей и проверки устаревших алгоритмов шифрования. Мой коммент: если всего 80 сейфчеков, то звучит как-то недостаточно. 🤷‍♂️

2. Специализированные проверки. Сканирование веб-приложений на XSS, SQL-инъекции и другие уязвимости из OWASP Top 10. Проверки контейнеров Docker и Kubernetes. Retro Scan - мгновенный поиск по ранее собранным данным без повторного подключения к активам.

3. Мультисканер и работа в изолированных сетях. Поддерживается одновременная работа с любыми (Мой коммент: тут, естественно, не совсем с любыми, а с теми, для которых интеграции запилены 😉) сторонними решениями (MaxPatrol, Tenable, Nessus, Qualys и др.). Для изолированных сегментов без прямого доступа есть отчуждаемый агент и цепочка прокси-компонентов.

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

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

Мой коммент: видим, что в первых трёх пунктах перечисляются режимы детектирования и поддерживаемые системы; в двух последних пунктах методы приоритизации уязвимостей с закосом в CTEM.

🎯 Какую выгоду получает ваш бизнес?

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

2. Снижение рисков. Граф достижимости помогает понять реальную угрозу, а приоритизация по EPSS и CISA KEV сфокусироваться на том, что действительно опасно.

3. Экономия ресурсов. Автоматизация сканирования и гибкие расписания снижают нагрузку на команду, а возможность точечного ретроскана экономят время.

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

Мой коммент: "проактивная защита", отчёты, EPSS/CISA KEV выглядят как универсальные фичи практически для всех VM-вендоров; а вот ретросканы и граф достижимости - довольно редки.

Заключительный мессадж: "Security Vision VS - это рентген для IT-инфраструктуры. Он помогает видеть слабые места, оценивать реальные риски и защищать бизнес до того, как атака произойдёт. Просто, быстро, эффективно!"

Мой коммент: тут тоже мессадж более-менее универсальный.

В целом, мне ролик понравился, отторжения никакие тезисы не вызвали. 👍

О правильном понимании термина "exposure" ("экспозиция") в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз)

О правильном понимании термина exposure (экспозиция) в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз)

О правильном понимании термина "exposure" ("экспозиция") в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз). Я решил вернуться к этому вопросу, более-менее подробно описать историю использования термина "exposure", а также обосновать, почему я считаю корректным определять термин "exposure" как "уязвимость в широком смысле". Сделаю я это на основе своих выступлений и дискуссий на конференциях Security Summit, Территория Безопасности и Периметр, а также семинаре компании "Киберпротект", проходивших этой весной.

Повторюсь, что у меня к термину "exposure" отношение непростое. Был период, когда он мне категорически не нравился, и я выступал против его использования. Но постепенно, как в знаменитой книге Дейла Карнеги, я перестал беспокоиться и научился с ним жить. 🙂

🎓 (НЕ)Использование в академической ИБ

Когда мы говорим об уязвимостях ("vulnerability"), мы обычно понимаем под этим ошибки программного обеспечения, "баги", которые злоумышленники могут использовать для реализации своих зловредных целей. Всё у чего есть CVE или БДУ идентификатор - это уязвимость. При этом если посмотреть формальное определение уязвимости, то оно окажется гораздо более широким. У ФСТЭК это "слабость актива или управления, эксплуатация которой приведёт к реализации одной или нескольких угроз" (ISO/IEC 27000:2014) или "Недостаток (слабость) программного (программно-технического) средства или информационной системы в целом, который (которая) может быть использована для реализации угроз безопасности информации" (ГОСТ Р 56545-2015). В глосарии NIST самое популярное определение уязвимости, используемое в 17 документах, звучит так: "слабость в информационной системе, процедурах обеспечения безопасности системы, внутренних контролях или реализации, которая может быть эксплуатирована или задействована источником угрозы".

А откуда взялось "exposure"? Это слово очень многозначное как в самом английском языке, так и при переводе на русский. В зависимости от контекста его могут переводить как подвергание, выставление, выставка, местоположение, обнажение, вид и т.д.

В академической информационной безопасности термин "exposure" практически не используется. Если термин "vulnerability", согласно глоссарию NIST встречается в 39 документах, то термин "exposure" только в двух:

🔹 В документе NIST SP 800-161r1-upd1 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations под "exposure" понимается "степень, в которой организация и/или заинтересованная сторона подвержена риску".

🔹 В документе NISTIR 8286 Integrating Cybersecurity and Enterprise Risk Management (ERM) под "exposure" понимается "комбинация уровней вероятности и воздействия для риска".

Несмотря на низкую академическую востребованность, термин "exposure" в настоящее время активно используется индустриальной ИБ-экосистемой (Gartner, крупные вендоры, консалтинговые и платформенные игроки), но в иных смыслах.

⚙️ Эпоха Tenable

Одним из главных популяризаторов термина стала компания Tenable, которая с 2017 года начала продвигать концепт "Cyber Exposure" как "новую развивающуюся дисциплину управления и измерения современной поверхности атаки, позволяющую точно понимать и снижать киберриски" (Tenable Delivers Record Results in Q2 and the First Half of 2017). Однако при описании этого "Cyber Exposure" они используют термин "exposure", не определяя его. 🤷‍♂️ "Cyber Exposure также обеспечивает непрерывную видимость того, где активы защищены, а где они находятся в состоянии exposure и в какой степени, а также приоритизирует устранение проблем на основе критичности актива для бизнеса и степени выраженности exposure". Себя Tenable начали называть "Cyber Exposure company".

Также в 2017 году Tenable представили Cyber Exposure ecosystem - интеграционную экосистему, объединяющую инструменты безопасности и IT (ServiceNow, AWS, Splunk и другие) для сквозного управления киберриском за счёт обмена данными, автоматического обнаружения активов и ускорения приоритизации и устранения уязвимостей на всей современной поверхности атаки.

К 2019 году у Tenable "Cyber Exposure" уже используется как измеряемая модель киберриска: в Tenable Lumin они вводят Cyber Exposure Score, который объединяет вероятность эксплуатации уязвимостей и критичность активов, позволяет количественно оценивать уровень "exposure", сравнивать его во времени и между организациями и использовать это для приоритизации устранения рисков и принятия риск-ориентированных решений.

Таким образом, можно сказать, что до начала 2020-х годов термин "exposure" в рамках материалов Tenable не имел единого фиксированного самостоятельного определения и использовался как "плавающий" термин-оболочка, которому в разных контекстах придавались различные значения: от обозначения новой дисциплины управления и измерения киберриска, до общей подверженности риску, состояния уязвимости активов, степени их "открытости" атаке, агрегированного риска (с учётом вероятности и ущерба), интеграции уязвимостей и конфигураций в единую модель, а также количественного скоринга для ранжирования и приоритизации устранения проблем. 🤯

Читать далее →

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире. Сама статья за paywall-ом, и мои комментарии там, вполне естественно и ожидаемо, были сильно сокращены, поэтому я приведу их здесь в развёрнутом виде.

Насколько адекватно делать выводы о динамике раскрытия уязвимостей, основываясь только на БДУ ФСТЭК России? (такую статистику привели коллеги из ЛК, привязав к ней анонс Kaspersky VM 😉)

Говоря о базе уязвимостей БДУ ФСТЭК России, важно учитывать, что она методологически не предназначена для учёта всех существующих уязвимостей: в неё включаются данные об уязвимостях отечественных продуктов, а также иностранных коммерческих и опенсорсных решений, применяемых в ГИС и на объектах КИИ. Поэтому БДУ не покрывает весь спектр уязвимостей, актуальных для российских инфраструктур, и её данных недостаточно для анализа глобальных трендов; для этого лучше использовать более полные источники, такие как PT DBugs или NIST NVD. Для визуализации статистики NVD удобно использовать дашборды, такие как CVE ICU. Текущие данные NVD показывают значительное увеличение скорости добавления новых CVE: за одинаковый период в 2025 году было зарегистрировано 22 041 уязвимость, а в 2026 году уже 31 917, что соответствует увеличению на 44,8%.

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

Что сейчас происходит с Vulnerability Management рынком?

Рынок Vulnerability Management в последние годы растёт как в России, так и в мире. В России важным фактором стал уход западных вендоров в 2022 году, что привело к появлению новых отечественных игроков. Внутренняя конкуренция стимулирует развитие функциональности решений, повышение качества детектирования, точности приоритизации и расширение интеграций с другими средствами защиты и ИТ-системами. Отдельно стоит отметить внимание ФСТЭК России к этой теме: разработка методических документов и требований способствует формированию более структурированного подхода к управлению уязвимостями.

Если смотреть ретроспективно, рынок Vulnerability Management прошёл путь от массового сканирования и детектирования CVE-уязвимостей к платформенному управлению защищённостью инфраструктуры. Полный и качественный поиск уязвимостей остаётся важной базовой функциональностью, однако сегодня всё больше учитывается контекст: критичность затронутых активов и возможность реальной компрометации через комбинацию выявленных уязвимостей. На Западе всё чаще говорят не о классическом Vulnerability Management, а о более широком подходе - Exposure Management или Continuous Threat Exposure Management (CTEM), где объектом управления становятся не только уязвимости с CVE/BDU-идентификаторами, но и уязвимости в широком смысле ("экспозиции"): ошибки конфигурации, проблемы с учётками, небезопасные настройки, избыточная сетевая связность активов и т.п. Обнаруженные проблемы используются CTEM-решениями для моделирования возможных путей развития атаки (attack paths), что позволяет выявлять и приводить в порядок наиболее проблемные участки инфраструктуры, повышая сложность и стоимость реальной атаки для злоумышленников.

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