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

Qualys переупаковывают детектирование уязвимостей по ранее собранным данным инвентаризации ("сканирование без сканирования") в технологию InstaScan.

Добавить комментарий

Qualys переупаковывают детектирование уязвимостей по ранее собранным данным инвентаризации (сканирование без сканирования) в технологию InstaScan.Qualys переупаковывают детектирование уязвимостей по ранее собранным данным инвентаризации (сканирование без сканирования) в технологию InstaScan.Qualys переупаковывают детектирование уязвимостей по ранее собранным данным инвентаризации (сканирование без сканирования) в технологию InstaScan.Qualys переупаковывают детектирование уязвимостей по ранее собранным данным инвентаризации (сканирование без сканирования) в технологию InstaScan.

Qualys переупаковывают детектирование уязвимостей по ранее собранным данным инвентаризации ("сканирование без сканирования") в технологию InstaScan. Основной мессадж: развитие ИИ сократило время между публикацией CVE и появлением эксплоитов до нескольких часов. InstaScan сопоставляет новые CVE с уже собранными данными об активах, ПО и телеметрией без запуска новых сканов. Результаты затем подтверждаются существующими агентами и сканерами и используются для приоритизации, проверки эксплуатируемости и устранения уязвимостей.

Предпосылки появления InstaScan:

🔹 В 2025 году опубликовано 48 177 CVE, в 2026 году ожидается около 59 000.

🔹 Медианное время до появления первого эксплоита сократилось с 56 дней (2024) до 23 дней (2025); для отдельных CVE - 4-12 часов.

🔹 По данным Verizon DBIR, эксплуатация уязвимостей выросла на 34% год к году и является начальным вектором примерно в 20% инцидентов.

🔹 Регуляторы (например, CISA и CERT-In) требуют устранять отдельные уязвимости в течение 12-24 часов.

🔹 Традиционное сканирование выявляет новые уязвимости через 24-36 часов после публикации CVE из-за зависимости от расписания сканирований, обновления сигнатур и повторной оценки данных агентами. Дополнительные ограничения - разрозненные источники данных и необходимость согласований при проведении проверок.

InstaScan, работающий на базе Agent Insta, позиционируется как "первая в отрасли функциональность обнаружения уязвимостей без сканирования" (scanless detection capability). Agent Insta - внутренний backend-компонент Qualys, работающий в режиме 24×7. Он сопоставляет новые advisory от вендоров с данными о ПО, телеметрией активов, информацией об экспозициях и контекстом угроз, собранными из инструментов Qualys и сторонних решений. Это позволяет выявлять потенциально затронутые активы без ожидания окна сканирования. Утверждается, что для технологий, составляющих 60-70% типичного объема уязвимостей в корпоративной среде, InstaScan обеспечивает мгновенное обнаружение более 90% экспозиций без запуска заданий сканирования.

5 этапов работы InstaScan:

🔻 Формирование данных инвентаризации ПО: InstaScan собирает данные из агентов сканирования, SBOM, CMDB, сенсоров Qualys и сторонних источников. Так как одно и то же ПО может описываться по-разному, система создаёт единую основу данных.

🔻 Нормализация идентификаторов ПО с помощью ИИ: AI-модель сопоставляет записи о ПО со стандартными идентификаторами CPE и PURL, даже при различиях в названиях и форматах.

🔻 Создание единого набора данных инвентаризации: AI-сопоставления получают оценку уверенности (AI-generated match is confidence-scored), после чего дублирующиеся записи объединяются для поддержания точности данных.

🔻 Непрерывный мониторинг угроз: Agent Insta работает 24×7, получает данные о CVE, уведомления вендоров и информацию об угрозах по мере появления и преобразует их в данные для обнаружения.

🔻 Корреляция и подтверждение: InstaScan сопоставляет данные об угрозах с данными инвентаризации, используя агенты, сканеры, сенсоры Qualys и телеметрию сторонних решений. Проверяются актуальность данных, точность сопоставления, соответствие активу и критичность. В TruRisk передаются результаты с высокой степенью уверенности.

🤔 Моё мнение: маркетологи Qualys красиво представляют развитие ставшей уже традиционной функциональности как нечто принципиально новое. "Сканирование без сканирования", там где это возможно, - это полезная фича, и ей нужно пользоваться. Но потребность в качественной и полной инвентаризации инфраструктуры такая технология, конечно же, не снимает. Если данные, по которым производился анализ, будут неполными и устаревшими, то и детектирование уязвимостей по ним будет некорректным и принесёт больше вреда, чем пользы.

В свежем выпуске журнала Information Security вышел традиционный спецпроект по Управлению Уязвимостями, в котором я принял участие

Добавить комментарий

В свежем выпуске журнала Information Security вышел традиционный спецпроект по Управлению Уязвимостями, в котором я принял участие

В свежем выпуске журнала Information Security вышел традиционный спецпроект по Управлению Уязвимостями, в котором я принял участие. Всего там было опубликовано 10 материалов. Если суммировать, то в этом году эксперты в основном разбирали ограничения классического VM-подхода: рост числа CVE, недостаточность CVSS, необходимость учета реальной эксплуатабельности уязвимостей и контекста активов, переход к Exposure Management / CTEM, Realtime VM, TPRM и автоматизации приоритизации и устранения уязвимостей. Вот перечень материалов и краткие выжимки:

🔻 Виктория Шишкина, Positive Technologies. От хаоса к контролю: ошибки в управлении уязвимостями и метрики зрелости процесса. Эффективное управление уязвимостями невозможно без измеримых метрик, которые позволяют контролировать полноту инвентаризации активов, качество выявления, приоритизацию и своевременность устранения уязвимостей и ошибок конфигурации.

✳️🔻 Александр Леонов, Positive Technologies. CVE - только начало: Как Exposure Management меняет правила игры. Exposure Management расширяет классическое управление уязвимостями: вместо фокусировки только на CVE он учитывает любые факторы, повышающие риск атаки (ошибки конфигурации, избыточные права, слабые настройки и архитектурные недостатки), анализирует реальные пути атак и помогает устранять наиболее опасные экспозиции с учетом бизнес-контекста.

🔻 Security Vision. Восемь слагаемых процессов VM нового поколения. Современные платформы управления уязвимостями должны не просто находить CVE, а непрерывно оценивать реальные риски, анализировать поверхность и маршруты атак, контролировать устранение и объединять все процессы в единую систему управления безопасностью.

🔻 Мария Тимофеева, RedCheck. Проблемы источников сведений об уязвимостях в 2026 году. Из-за роста числа уязвимостей, ограничений CVSS и снижения полноты данных в NVD компании переходят к многоканальному сбору сведений, риск-ориентированной приоритизации и усилению роли экспертной аналитики и ИИ в управлении уязвимостями.

🔻 Владимир Михайлов, Vulns io. Realtime VM для противодействия эксплуатирующему ИИ. Переход от периодического сканирования к Realtime VM позволяет за счет непрерывного контроля инфраструктуры, оперативного обновления данных об уязвимостях и автоматизации устранения сократить время реакции на новые угрозы с часов до минут.

🔻 Никита Котиков, CICADA8. Иллюзия контроля: почему Excel-анкеты не защищают от атак через контрагента. Оценка рисков контрагентов должна переходить от формальных Excel-анкет к доказательному и непрерывному контролю через TPRM (Third-Party Risk Management), который анализирует реальные технические данные, выявляет скрытые риски и обеспечивает постоянный мониторинг безопасности цепочки поставок.

🔻 Александр Дорофеев, Эшелон Технологии. Внешние индикаторы реальной опасности уязвимостей. Эффективная приоритизация уязвимостей требует отказа от оценки только по CVSS и учета дополнительных индикаторов - вероятности эксплуатации EPSS, фактов атак из CISA KEV, наличия эксплойтов, критичности активов и внутреннего контекста риска.

🔻 Иван Елисеев, Check Risk. Неужели VM-системы подходят к пределу своих возможностей? VM-системы сталкиваются с ограничениями из-за роста числа CVE, ускорения появления эксплойтов и снижения эффективности приоритизации по CVSS/EPSS, поэтому рынок смещается к Exposure Management, где оценивается не сама уязвимость, а реальная вероятность атаки с учетом доступности актива, эксплуатируемости и бизнес-контекста.

🔻 Круглый стол экспертов. Эволюция VM или смена парадигмы? VM эволюционирует от простого поиска и закрытия уязвимостей к управлению реальными киберрисками: платформы должны учитывать бизнес-контекст, помогать принимать решения по остаточному риску, работать с новыми активами вроде ИИ-агентов, анализировать пути атак, внедрять принципы CTEM и становиться частью более широких платформ управления экспозициями и киберустойчивостью.

🔻 Российские решения для управления уязвимостями. Сравнительная таблица MaxPatrol VM, Security Vision NG VM, RedCheck, Сканер-ВС, Vulns.io VM, CICADA8 VM, Kaspersky VM. Критерии сравнения включают сертификацию и наличие в реестрах, позиционирование, охват активов, возможности внешнего сканирования, источники данных об уязвимостях и активах, ИИ-анализ, приоритизацию, подтверждение эксплуатации, анализ путей атак, автоматизацию устранения, интеграции и дополнительные функции.

Вчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. Баумана

Добавить комментарий

Вчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. Баумана

Вчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. Баумана. Альма-матер, конечно, растёт и хорошеет. Первое, что удивило на подходе, - автомобильное движение возле Главного Здания (ГЗ) стало гораздо менее оживлённым, потому что дорогу сузили до одной полосы в каждую сторону. Переходить дорогу теперь стало безопасно, поэтому и светофоры убрали. Такую урбанистику я одобряю. 👍

Новые корпуса рядом с ГЗ поражают масштабом и архитектурой. 😮 Когда я подходил, моросил дождик. То, что площадь между корпусами закрыта навесом, было очень в тему. 😇 Новые корпуса рядом с ГЗ - это небольшая часть. Посмотрите на фотографии макета: везде, где горит свет, это всё теперь Бауманка. 😎

Само мероприятие проходило в студенческом коворкинге Т-Банка, что мне было отдельно приятно, учитывая, сколько долгих и счастливых лет я проработал в Тиньке.

Кроме меня, в качестве экспертов в мероприятии приняли участие Дмитрий Калинин и Аркадий Никифоров из Бастион. Дмитрий руководит департаментом по работе с уязвимостями информационных систем, а Аркадий руководит разработкой инструментов кибербезопасности. Вела мероприятие Олеся Томах с кафедры ИУ-10 МГТУ. В аудитории было около 25 ребят, окончивших 7-8 класс.

Мы начали с рассказа про Positive Technologies и Бастион, и о своих ролях в этих компаниях. Затем обсудили в интерактивной форме разнообразные темы из мира Информационной Безопасности:

🔹 Что такое Vulnerability Management, чем отличается CVE и CWE;
🔹 Важность своевременной установки обновлений безопасности;
🔹 Контроль сетевого периметра (на ярком примере взлома казино через аквариум 😅);
🔹 Zero-click уязвимости мобильных устройств;
🔹 Какую информацию могут собрать умные колонки, пылесосы и камеры в автомобилях.

Много времени уделили вопросу применения искусственного интеллекта в ИБ. Эта тема сейчас, безусловно, волнует всех независимо от возраста. 💯

Также поотвечали в блиц-режиме на вопросы об учёбе и работе.

Время в оживлённой беседе пролетело незаметно. Ребята на интенсиве собрались хорошие, заряженные. Надеюсь, многие из них свяжут свою жизнь с Информационной Безопасностью.

Спасибо большое организаторам за приглашение поучаствовать!

Разбор VM-ной вакансии от R-Vision "Инженер-аналитик по выявлению уязвимостей"

Добавить комментарий

Разбор VM-ной вакансии от R-Vision Инженер-аналитик по выявлению уязвимостей

Разбор VM-ной вакансии от R-Vision "Инженер-аналитик по выявлению уязвимостей". Давненько не было у меня постов в этой рубрике. Но вот попалась вакансия в R-Vision, которая очень характерна для VM-вендоров. Я и сам на похожей позиции начинал свой путь в Vulnerability Management. 😇

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

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

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

🔻 Заниматься разработкой и формированием экспертизы (технические стандарты безопасности и информация по уязвимостям) в области информационной безопасности для продуктов компании;

И наконец, нужно написать скрипт, который будет автоматически генерировать правила детектирования уязвимостей:

🔻 Автоматизировать процессы по формированию экспертизы ИБ;

Таким продуктом при этом может быть всё, что угодно: операционные системы, базы данных, ERP-системы, сетевые устройства, разнообразный прикладной софт. Так как у клиентов, как правило, лютейший зоопарк, загрузка работой обеспечена на годы вперёд. 😉 Хотя с появлением нейроночек процесс упростился и ускорился.

Обратите внимание, что выше было про "технические стандарты безопасности". Это про харденинг. На вход аналитику подаётся стандарт по безопасному конфигурированию какого-то продукта (например, от CIS, ФСТЭК или самого вендора продукта). Задача аналитика - разработать для каждого требования автоматическую проверку конкретной инсталляции продукта на соответствие этому требованию. Пока накидываешь проверки, волей-неволей разбираешься и с безопасным конфигурированием. 👍

Все разработанные проверки будут работать в рамках конкретного решения (видимо, R-Vision VM, но возможно, что и не только), поэтому соискателю неизбежно придётся:

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

Какие скиллы нужны для этой работы? Ну, очевидно, что нужно уметь как-то кодить:

🔸 Знание Git, Python - ваши хорошие друзья;

Очевидно, что соискатель не должен бояться консоли и должен +- быть в курсе, что из себя представляет современная IT-инфраструктура:

🔸 Наличие навыков администрирования Windows, Linux систем;
🔹 Опыт администрирования сетевого и иного оборудования;

Чёткого ТЗ на такой позиции ждать не приходится. Придётся много копать самому, поэтому:

🔸 Способность работать самостоятельно, но и в команде.

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

🔹 Опыт проведения работ по инструментальному анализу защищенности или опыт работы с одним из сканеров безопасности (Nessus, Nexpose, Qualys, Max Patrol, OpenVas, RedCheck, nmap);
🔹 Навыки работы с режимом "Комплаенс" для оценки соответствия;

Тут не могу не поправить коллег, что MaxPatrol пишется в одно слово, и не "OpenVas", а OpenVAS. 😉

Также было бы неплохо, чтобы и про уязвимости соискатель тоже что-то знал:

🔹 Знание актуальных угроз и уязвимостей на Windows/ Linux платформах;
🔹 Опыт применения методологий по описанию, приоритизации и устранению уязвимостей (CVE, CVSS, VPR, OWASP);

Хотя, честно говоря, увидеть в списке сплошь проприетарный Tenable VPR (Vulnerability Priority Rating) было неожиданно. Интересно, что именно имеют в виду под OWASP. OWASP Top 10? 🤔 И в случае R-Vision странно, что в этом списке нет OVAL.

А в этом пункте коллеги намекнули на внутреннюю кухню:

🔹 Понимание принципов работы инструментов автоматизации (Apache Airflow);

Интересно было бы послушать, как именно они Apache Airflow используют при создании VM-ной экспертизы. 😉

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять

Добавить комментарий

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять. Сейчас на Западе очень популярна тема Вульнпокалипсиса (Vulnpocalypse). Этот термин обозначает ситуацию, когда скорость обнаружения уязвимостей и появления эксплойтов для них начинает значительно превосходить скорость выпуска обновлений безопасности вендорами ПО и скорость установки этих обновлений их клиентами. В принципе, это уже сейчас похоже на правду: количество CVE растёт настолько быстро, что NVD отказались от анализа всех CVE. Microsoft Patch Tuesday вырос примерно со 100 исправляемых уязвимостей в месяц до 500+. Аналогично, каждый месяц обновляются рекорды по числу уязвимостей в отчётах Linux Patch Wednesday.

Причиной этого обычно называют развитие технологий искусственного интеллекта. И с этим можно отчасти согласиться: ИИ действительно значительно упростил поиск уязвимостей и разработку инструментов для их эксплуатации. Но, на мой взгляд, настоящая причина такого количества уязвимостей - не в ИИ, а в качестве ПО. Десятилетиями вендоры ПО писали ОЧЕНЬ плохой код. Их цель была одна - реализовать как можно больше фич за наименьшее время и наименьшие деньги. Если разработку можно было отдать на аутсорс в страны с максимально дешёвой рабочей силой и низкой культурой разработки - её отдавали. Если можно было взять бесплатный код, непонятно кем написанный и выложенный в открытый доступ (я про open source) - его использовали. В результате мы имеем то, что имеем: огромное количество уязвимостей в этом коде.

Раньше это было не так заметно, т.к. скорость прироста выявленных уязвимостей ограничивалась возможностями специалистов-ресёрчеров. А они в первую очередь искали уязвимости там, где за это платили. Как только это ограничение начало сниматься благодаря ИИ-сервисам, уязвимости начали массово проявляться. 😏 Есть основания полагать, что с развитием ИИ-инструментов темпы роста обнаруживаемых уязвимостей будут только расти.

С ростом количества уязвимостей растёт и количество обновлений, которые необходимо тестировать и устанавливать в инфраструктурах. Обновлений будет МНОГО, гораздо больше, чем было раньше. И выходить они будут ещё чаще. Сложившаяся ситуация - это плата за то, что вендоры софта могут писать плохой код, лепить из него продукты, а затем годами выпускать бесконечные заплатки для этих продуктов. А компании-клиенты готовы такие продукты покупать и использовать. 🤷‍♂️

При этом имеет место довольно занимательная ситуация. Покупать продукты клиенты готовы, а выполнять рекомендации вендоров ПО по устранению уязвимостей в купленных продуктах (устанавливать обновления, менять конфигурацию и применять другие меры защиты) они НЕ ГОТОВЫ. И ищут "индульгенции", чтобы этого не делать.

И находят! 🙂 Есть Vulnerability Management (Exposure Management)-вендоры, которые в своём маркетинге транслируют, что "нужно устранять только 1-3% уязвимостей". Только купите их решение, и они вам этот минимальный список уязвимостей покажут. 🔮 Это, конечно, безответственное шарлатанство, потому что супер-критичные уязвимости появляются из общего пула всех неустранённых уязвимостей. И появляются ВНЕЗАПНО! Сегодня уязвимость может не представлять особого интереса, а завтра стать супер-критичной из-за появления публичного эксплоита или обнаружения признаков эксплуатации уязвимости в реальных атаках. Если бы в компании своевременно устранили эту уязвимость по рекомендации вендора ПО, эта супер-критичная уязвимость им бы не была страшна, но, доверившись недобросовестному VM/EM-вендору, вместо планового устранения они получают ещё один "пожар", который может привести к серьёзному инциденту. Таким образом, вместо экономии ресурсов получается бесконечный забег по граблям.

Попытки заранее прогнозировать, какие уязвимости станут супер-критичными, предпринимаются, но их эффективность, мягко говоря, не впечатляет. Например, тот же EPSS частенько показывает высокую вероятность появления эксплоита там, где всё потом годами глухо, и показывает всё по нулям там, где есть и эксплоиты, и атаки. 🥴 С уязвимостями, у которых есть подробные публичные разборы, эксплоиты и контекст от исследователей прогнозирование более-менее работает. Но для большинства уязвимостей, например для тысяч уязвимостей в ядре Linux, такой информации просто нет. Поэтому и утверждать, что конкретную уязвимость можно игнорировать на основе куцего описания из NVD, абсолютно неадекватно и непрофессионально.

Я, конечно, не говорю, что приоритизировать уязвимости - это плохо. Вполне полезно показывать клиентам уязвимости, которые требуют немедленного внимания, в том числе через моделирование путей атаки. Но как только VM-вендор меняет риторику с "эти уязвимости нужно устранить в первую очередь" на "остальные уязвимости можно игнорировать" - это переход на тёмную сторону. 😈

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

У Антона Чувакина, в прошлом главного идеолога Gartner по Vulnerability Management, недавно вышел блогпост, в котором он предлагает провести мысленный эксперимент:

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

Теперь самое интересное - попробуйте разобраться, как это стало возможным.

Какие фундаментальные изменения должны были произойти в вашей инфраструктуре, чтобы такое 15-минутное окно стало реальностью?

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

Приведет ли это всю компанию к 15-минутному циклу установки исправлений? Скорее всего, нет, особенно если речь идет об устаревших системах. Но это даст вам четкую, практическую дорожную карту для модернизации вашей ИТ-инфраструктуры."

Ну а стратегически хотелось бы, чтобы безнаказанный выпуск дырявого ПО, предполагающий постоянный патчинг, когда-нибудь прекратился. И чтобы компании-клиенты стали использовать продукты от вендоров, которые инвестируют не только в поиск уязвимостей, но и в безопасную разработку кода по принципу secure by design. Да, такие решения стоили бы гораздо дороже. Но если продукт по факту имеет меньше уязвимостей и реже требует экстренных обновлений, его эксплуатация становится значительно проще и безопаснее. "Жаль только - жить в эту пору прекрасную. Уж не придется - ни мне, ни тебе." © 😉

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ

2 комментария

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ. Т.е. использование ИИ для разработки эксплоитов на основе патчей и публичной информации об уязвимостях. Новую неизвестную уязвимость нужно ещё понять, где искать. А найдя, придумать вменяемый сценарий атаки с эксплуатацией этой уязвимости. Это работа на удачу, своего рода золотоискательство или, вспоминая Маяковского: "…та же добыча радия. В грамм добыча, в годы труды. Изводишь единого слова [уязвимости] ради тысячи тонн словесной руды [проверенного кода и неподтвердившихся гипотез эксплуатации]." Конечно, в случае использования ПО с открытым кодом задача анализа упрощается. Но всё равно найти что-то стоящее весьма непросто. Поэтому, кстати, я противник того, чтобы результаты этой добычи бесконтрольно утекали за рубеж.

Другое дело, когда уязвимость уже известная, с присвоенным CVE, вендорским описанием, признанной критичностью и выпущенным патчем. Тут задача серьёзно упрощается.

🔹 Понятно, где искать. Очевидно, там, где вендор исправляет что-то патчем.

🔹 Понятно, что нужно получить в результате. То, о чём вендор сообщил в описании уязвимости.

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

Естественно, этим занимаются не только исследователи watchTowr Labs. 😏 Тем более, что ИИ-агенты значительно упрощают процесс вепонизации, а то и полностью его автоматизируют. Как сообщает Денис Макрушин, стоимость автономной разработки эксплоита сейчас может составлять даже меньше 3 долларов. И ведь прогресс в ИИ пока не останавливается! Разработанные эксплойты могут выкладываться исследователями в паблик ради самопиара и общественного блага (ну, как они его себе видят), а могут и не выкладываться, а, например, продаваться на чёрном рынке. 😈 А затем эти эксплоиты будут использоваться в атаках на организации, пока их не спалят и факт эксплуатации уязвимости не станет подтверждённым. И всё это бесконечно повторяется для всё новых и новых уязвимостей. It's the circle of life and it moves us all…

Что вся эта движуха означает для простого VM'щика? Нарратив, который двигали многие VM-вендоры: "Патчьте только 3% уязвимостей, которые мы вам подсветим, а на остальные просто забейте", с самого начала выглядел булшитненько и безответственно, а в условиях ускорения и удешевления вепонизации n-day-уязвимостей и подавно. Аргументов, что любая уязвимость может внезапно выстрелить и привести к инциденту, значительно прибавилось. А значит, нужно стремиться к приоритизированному устранению всех уязвимостей, что создаёт значительную нагрузку на IT, особенно если IT-инфраструктура организации не была изначально рассчитана на непрерывную установку и тестирование обновлений безопасности. 🤷‍♂️ То, что VM-щик сможет запросто влиять на изменение инфраструктуры организации - сценарий более чем оптимистичный, на который не стоит всерьёз рассчитывать. Но агитировать за такие архитектурные изменения и стараться заводить задачи на устранение всех выявленных уязвимостей - святая обязанность VM-щика. Делай, что должен, и будь, что будет.

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

2 комментария

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