Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1

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

Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1
Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1

Посмотрел вчера вебинар R-Vision, посвящённый презентованному на прошлой неделе релизу R-Vision VM 6.1. На лайв-демо коллеги из R-Vision показали следующие кейсы (см. скриншоты):

🔻 Провели inventory-скан (показали новую карточку скана с фильтрами ошибок), определили хосты Cisco, создали и запустили простое правило для перемещения хостов в группу по типу ОС. В итоге наполнили группу "Сетевое оборудование Cisco".

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

🔻 Добавили уязвимость Cisco, которой не было в базе, через обновление и определили её ретроспективным аудитом на хостах. Проговорили, что в случае детектирования трендовой уязвимости можно автоматически отправлять алерт админу. 🚨

Также они поделились достижениями, статистикой, роадмапом и ближайшими мероприятиями.

Основное достижение - это перевод R-Vision на новую платформу EVO (до версии 5.4 были на платформе RVN).

R-Vision VM в цифрах (2025-2026):

🔹 +15 новых проектов (есть заказчики с 30k+ активов)
🔹 +50 пилотных проектов у клиентов
🔹 +25 пилотных проектов у партнёров
🔹 +55 обученных технических специалистов
🔹 +133 трендовые уязвимости в базе (дайджесты доступны на сайте R-Vision)
🔹 +180 поддерживаемых продуктов в режиме Audit
🔹 +88 поддерживаемых продуктов в режиме Pentest
🔹 +70 новых стандартов для режима Compliance

Роадмап ("R-Vision VM завтра"):

🔹 Поддержка аудита контейнерных сред
🔹 Поддержка аудита веб-приложений
🔹 Расширение аудита гипервизоров (ESXi, vCenter, …)
🔹 Расширение аудита сетевого оборудования (Qtech, S-Terra, Eltex, VipNET, UserGate, MikroTik, …)
🔹 Мастер первичной настройки
🔹 Сертификат ФСТЭК России (на VM EVO)
🔹 + Секретная функциональность ❗️ (анонс на R-Evolution Conference 2026)

Сам я на R-Evolution Conference, к сожалению, в этом году не попадаю. 😔 Но рекомендую сходить, был там несколько раз, мероприятие душевное.

На R-Evolution Conference будет несколько VM-ных докладов:

🔹 12:55 - 13:15 Смена двигателя на лету: год большой перестройки VM и куда дальше? (Бизнес-трек)
🔹 14:00 - 14:20 Опыт ТМХ: как выстроить управляемый VM на десятках тысяч активов (Бизнес-трек)
🔹 15:20 - 15:40 Где ломается VM: подводные камни инвентаризации в инфраструктуре на 18К+ активов, ЗАО ПАТИО (Технотрек - новинка, в прошлом году технотрека не было 👍)

Плюс обещают демозону с R-Vision VM, работающую весь день. 🔥

В Q&A секции понравились вопросы:

🔹 Какая функциональность будет востребована в системах VM в ближайшие 2-3 года?
"Управление экспозициями" (прямо так и сказали, было приятно услышать именно такую формулировку 😇), пути атаки, ИИ, возможность переваривать большую инфраструктуру, автоматизация.

🔹 Можно ли сейчас использовать решения R-Vision для построения путей атаки?
Сказали, что тема хорошая, но задача сложная, особенно для большой инфраструктуры. Пока они не говорят, что могут это делать, но тренд им нравится.

🔹 Сколько человек, занимающихся VM-ом, требуется для организации с 10k активов?
Ответили, что 10000 активов → минимум 10 человек в IT, минимум 5-7 человек в ИБ. В ИБ люди будут шарить роли. Как минимум нужен один человек, который будет часть времени выделять на VM-ные задачи. Автоматизировать всё можно, но кто-то должен отслеживать сбои.

Почитал, что там пишут про вторую серию инцидента с Trivy от Aqua Security

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

Почитал, что там пишут про вторую серию инцидента с Trivy от Aqua Security

Почитал, что там пишут про вторую серию инцидента с Trivy от Aqua Security. А там мощный движ! 🔥🙂 Вообще у меня всегда было весьма скептическое отношение к Trivy. В первую очередь из-за качества детектирования уязвимостей. Каждый раз, когда я пытался использовать его для анализа докер-образов, я наталкивался на какие-то жуткие фолз-позитивы. Причём логику детектирования уязвимостей было отследить весьма непросто. Поэтому я Trivy использовал только в крайних случаях. Если образ можно было просканировать, детектируя чётко по бюллетеням безопасности через Vulners API, - делал так. Если нельзя из-за того, что образ был на основе какого-то дистрибутива, который Vulners на тот момент не поддерживал (например Alpine), то вынужденно использовал Trivy. Лучше, чем ничего. И тем более Trivy же БЕСПЛАТНЫЙ! 🙂 И если не задумываться о качестве детектирования, то бесплатный сканер - это ведь очевидный и лучший выбор, так ведь? 😅 Правда, я Trivy не пользовался уже года 3-4. Возможно, что с детектированием уязвимостей ситуация у них стала получше. Но вот с собственной безопасностью похоже стало хуже. Иначе как объяснить, что вместо бесплатного сканера с официального репозитория Trivy на GitHub распространяется малварь (и это уже во второй раз за два месяца!). 😱

В конце прошлой недели, 20 марта, исследователь безопасности Paul McCarty сообщил о крупной атаке на цепочку поставок, нацеленной на Trivy.

"Внимание! Trivy версии 0.69.4 скомпрометирована ⚠️ Контейнерные образы и GitHub-релизы версии 0.69.4 являются вредоносными, поэтому если вы используете Trivy в CI, стоит срочно обратить на это внимание. К счастью, версия через Homebrew не была скомпрометирована, как я сообщал ранее. Вредоносная нагрузка представляет собой бинарный файл, и мы пока не провели его анализ, но обновим информацию, как только узнаем больше. Огромное спасибо команде, которая оперативно отреагировала сегодня - вы спасли ОЧЕНЬ много людей от крайне неприятного дня."

Подробности по малвари на opensourcemalware.

Разработчики часто встраивают Trivy в свои CI/CD-пайплайны - и это делает его особенно привлекательным для злоумышленников, поскольку позволяет им похищать API-ключи, учетные данные облаков и баз данных, токены GitHub, а также множество других секретов и чувствительной информации.

За атакой стоит группа TeamPCP. Им удалось это сделать, потому что ещё в феврале та же группа воспользовалась ошибкой конфигурации в GitHub Action Trivy и похитила токен с привилегированным доступом. Эта проблема безопасности так и не была полностью устранена, и позже, в марте, злоумышленники использовали этот токен для создания поддельных коммитов в Trivy.

Исследователи из Socket и Wiz в выходные установили подробности атаки, что атака затронула несколько компонентов проекта Trivy: основной сканер, GitHub Action trivy-action и GitHub Action setup-trivy. Злоумышленники принудительно обновили 75 из 76 тегов trivy-action до вредоносных версий, что означает: любой, кто использовал Trivy в своем пайплайне разработки, запускал инфостилер-вредонос при обращении к сканеру.

Исследователи также обнаружили, что TeamPCP расширила свои операции, начав заражать экосистему npm с помощью ранее неизвестного червя под названием CanisterWorm, используя похищенные publish-токены из первоначального взлома Trivy.

В воскресенье Socket зафиксировали дополнительные вредоносные образы, опубликованные в Docker Hub, а Paul McCarty отметил высокий импакт атаки: "44 внутренних репозитория были взломаны, переименованы и сделаны публичными - включая исходный код Tracee, внутренние форки Trivy, CI/CD-пайплайны, Kubernetes-операторы и базы знаний команд (team knowledge bases)". Socket отмечают, что, хотя полный масштаб доступа остаётся неясным, наличие этих репозиториев указывает на более глубокий уровень контроля во время компрометации.

Charles Carmakal, директор Mandiant Consulting, на мероприятии Google заявил:

"Нам известно о более чем 1 000 затронутых SaaS-средах, которые прямо сейчас активно сталкиваются с этим конкретным злоумышленником. Количество этих жертв, вероятно, вырастет ещё на 500, ещё на 1 000, возможно, ещё на 10 000. И мы знаем, что эти акторы сейчас сотрудничают с рядом других групп".

В общем, излишнее доверие к сторонним бесплатным компонентам и излишняя автоматизация вышли компаниям боком. Снова. 😏🍿

На прошлой неделе, 16 марта, прошло весьма интересное VM-ное мероприятие

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

На прошлой неделе, 16 марта, прошло весьма интересное VM-ное мероприятие

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

Первый доклад был от начальника отдела по надзору за исполнением законов в сфере информационных технологий и защиты информации Генеральной прокуратуры Олега Кипкаева. Приведу его содержание.

Олег Вячеславович сообщил, что в Рунете функционируют ~70 млн. сервисов, более половины исследованных хостов содержат нарушения базовых требований информационной безопасности. "Практика показывает, что в основе многих инцидентов лежат не какие-то исключительные обстоятельства, а несвоевременное обновление программного обеспечения, использование уязвимых версий сервисов, слабая парольная политика, открытый доступ к административным интерфейсам, отсутствие необходимых средств защиты, иные известные недостатки в настройке и эксплуатации информационных систем". Уязвимость внешнего цифрового периметра не проблема конкретной организации, а вопрос общей устойчивости цифрового пространства. Количество кибер-атак на отечественные организации продолжает расти, их цель нанесение существенного вреда. Необходимы упреждающие действия со стороны государства, регуляторов, правоохранительных органов и владельцев информационных систем. Правовая основа для работы создана: законодательство о безопасности КИИ, решение президента РФ, обязательные требования в сфере защиты информации, функционируют механизмы выявления/предупреждения/ликвидации последствий компьютерных атак. Но есть проблемы:

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

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

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

Требуются дополнительные меры организационного, правового и практического характера. Следует сосредоточить внимание на следующих направлениях:

🔹 Необходимо обеспечить системную работу по выявлению, учёту и обязательному устранению критических уязвимостей в установленные сроки. Эта деятельность должна вестись на постоянной основе по единым критериям и чётким определением опасности выявляемых недостатков.

🔹 Необходимо повысить уровень контроля за исполнением обязательных требований в сфере защиты информации, в первую очередь субъектов КИИ, органов публичной власти, системообразующих организаций и иных владельцев значимых информационных ресурсов.

🔹 Требует дальнейшего развития практика регулярного внешнего мониторинга публично доступных сервисов. Результаты такого мониторинга должны доводиться до уполномоченных должностных лиц. "Каждый руководитель должен иметь объективное представление о состоянии подведомственной инфраструктуры и понимать меру своей ответственности за непринятие своевременных мер".

🔹 Следует рассмотреть вопрос о совершенствовании мер ответственности за неустранение критических уязвимостей в случаях, когда такое бездействие "создаёт угрозу причинения существенного вреда государственным, общественным и частным интересам". Подход должен быть взвешенным. Если устранение уязвимости в кратчайшие сроки невозможно по объективным причинам, в т.ч. в связи с отсутствием необходимого обновления или необходимостью серьёзной технологической перестройки, должны незамедлительно приниматься компенсирующие меры защиты, позволяющие минимизировать риски.

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

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

❓ Уточняющий вопрос от Владимира Бенгина про то, касаются ли эти предлагаемые меры не только КИИ. Олег Кипкаев подтвердил, что всё так. "Регулирование КИИ, гос. информационных систем, информационных систем органов власти в целом урегулированы. Если говорить о бытовых информационных устройствах, которые используются гражданами в частных целях, а также юридическими лицами, это сейчас является самым уязвимым сектором в сети Интернет." Эта инфраструктура используется для DDoS атак на КИИ. Менее защищённая инфраструктура является опорной точкой для атаки на более защищённую инфраструктуру и её нельзя отсечь по GEO IP и т.д., т.к. эта угроза идёт уже изнутри РФ.

#️⃣ В целом, мои впечатления от доклада очень положительные. Эта инициатива может привести к появлению методических указаний по контролю сетевого периметра (возможно уточнению VM-ных методик ФСТЭК). Также помимо 274.1 УК РФ, возможно появятся и другие действенные аргументы, чтобы "взбодрить" ответственных за устранение уязвимостей. И будет очень здорово, если меры действительно будут касаться не только "КИИ, гос. информационных систем, информационных систем органов власти", но сетевого периметра любых организаций и даже физических лиц. Жаль, конечно, что уязвимостям внутрянки уделяется меньше внимания, но для начала хорошо и так. 🙂

Судя по статье в Ведомостях, именно это выступление привлекло наибольшее внимание, но я постараюсь и остальные выступления отсмотреть, законспектировать и прокомментировать. 😉

В этот четверг, 26 марта, я собираюсь выступить на московской конференции Security Summit "Стратегия и тактика информационной безопасности"

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

В этот четверг, 26 марта, я собираюсь выступить на московской конференции Security Summit Стратегия и тактика информационной безопасности

В этот четверг, 26 марта, я собираюсь выступить на московской конференции Security Summit "Стратегия и тактика информационной безопасности". У меня там будет короткий доклад про эволюцию Vulnerability Management-а в Exposure Management. Буду рассказывать про то, как мы все жили не тужили где-то с начала нулевых: детектировали и приоритизированно устраняли уязвимости и мисконфигурации, называя это "Управление Уязвимостями". А потом бац - в 2017 году маркетологи Tenable придумали для позиционирования своих решений на рынке использовать вместо уязвимостей слово "exposures" - максимально обтекаемое и неконкретное даже на английском, а тем более при попытках перевести его на русский. И эти самые "exposures" настолько зашли консалтерам из Gartner, что где-то с 2022 года они стали использовать их в хвост и гриву в рамках своей концепции "продвинутого VM-а" под аббревиатурой CTEM (Continuous Threat Exposure Management). И т.к. Gartner в деле ИБ-шного маркетинга могущественны и влиятельны, то сейчас на Западе VM практически закончился. 🤷‍♂️ У всех бывших VM-вендоров сплошной CTEM через CTEM, естественно определяемый так, как конкретному вендору выгодно. 😏 И, соответственно, масса сопутствующей маркетинговой активности: новые продуктовые ниши для решений (EAP, AEV, VPT, EASA, CAASM, APM, APA, BAS, Auto PT, CART, APS, TIP, DRPS, ASCA, X-SPM - можно подумать, что я рандомно стучу по клавиатуре, но нет 😅), новые квадранты, масса аналитики на тему (полезной и не очень). Работают люди! 😉

И тут, глядя на это западное маркетингово-консалтинговое пиршество духа из подсанкционной России, возникает вопрос: игнорировать его или интерпретировать (желательно не сильно противореча оригиналу) и попытаться извлечь некоторую практическую пользу (чтобы EM не выхолостился просто в модный синоним VM-а). Учитывая, что мы чай не в лесу живём, игнорировать не выглядит хорошим вариантом - всё это так или иначе сюда придёт и будет использоваться. Получается, следует включаться в это использование, чётко определяя, что такое exposures (экспозиции, "уязвимости в широком смысле"), что такое Exposure Management ("управление экспозициями"), что такое CTEM ("непрерывное управление экспозициями с учётом угроз") и какая функциональность для этих классов решений является ключевой и приносящей реальную пользу.

В общем, примерно таким будет выступление. Заглядывайте на мероприятие, пообщаемся. 🙂 Positive Technologies - генеральный партнёр, поэтому на стенде про PT-шный взгляд на CTEM тоже расскажем и покажем продукты, которые его реализуют. 😉

Количество подписчиков в моём MAX-канале перевалило за 200!

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

Количество подписчиков в моём MAX-канале перевалило за 200!

Количество подписчиков в моём MAX-канале перевалило за 200! Чему я несказанно рад. 😇 Я отлично помню, как рос мой первый англоязычный Telegram-канал @avleonovcom 9 лет назад. Когда там стало 100 подписчиков, я это считал прямо офигенным. Это же почти как выступать перед полной аудиторией в институте! И они меня читают! И, судя по просмотрам, регулярно! Ну ничего себе!

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

Очень отрадно видеть, что всё больше ИБ-каналов открывается в MAX: Positive Technologies, GIS, Kaspersky, CISOCLUB, Angara Security, Swordfish, InfoWatch, Похек. И это только публичные каналы! Теперь есть что почитать. 😉 Также я всё чаще общаюсь с коллегами VM-щиками именно в MAX.

Не устану повторять: Я АБСОЛЮТНО ДОВЕРЯЮ МЕССЕНДЖЕРУ MAX! И команде VK, которая за ним стоит и частью которой я когда-то был (тогда ещё Mail.Ru Group). Я не верю идиотским набросам про какую-то там слежку и небезопасность. У меня на основном десктопе стоит клиент MAX. У меня на основном телефоне стоит MAX. У всех моих родственников стоит MAX. И меня в нём всё устраивает. Жду, конечно, доступ физических лиц к API для постинга и свободную регистрацию публичных каналов. Но понимаю, что у команды разработки есть свой план и свои приоритеты. И, говоря начистоту, я этих фич, конечно, ОЧЕНЬ жду, но не настолько, чтобы зарегистрировать ИП и получить к ним доступ прямо сейчас. 🙂

С другой стороны, активная анти-MAX-овская позиция человека это для меня маркер, что с ним что-то не так. Зачем он саботирует внедрение национального мессенджера? В чём его интерес? Если он просто держится за свой ТГ-канальчик, который считает своим активом, источником влияния и дополнительного (а может, и основного) дохода - это ещё не такая большая беда. А если не только? Если человек имеет позицию, согласно которой неограниченный доступ западных спецслужб к переписке россиян - это благо? Как метко выразился в комментарии Reuters представитель экстремистской компании Meta: "WhatsApp глубоко встроен в ткань ("embedded in the fabric") каждого сообщества в стране - от родительских и рабочих групп до чатов друзей, соседей и расширенных семей по всем регионам России". Если человек за такое топит, то о чем это говорит? 🤔 Мой вам совет, если видите ЛОМа, который вам вещает, что с расчудесного Телеграма он никуда не уйдёт, призывает вас к обходу блокировок и рассказывает страшилки про MAX - делайте выводы и бросайте его читать. Этот ЛОМ доведёт вас до цугундера (и себя, вероятно, тоже).

Я за свой Telegram-канал не держусь. Я продолжу выкладывать контент в ТГ, пока это не запрещено. Как только будет прямой запрет - я свои каналы удалю. Основными своими ресурсами я считаю канал в MAX и сайт avleonov.ru. Я основательно потрудился на неделе, чтобы отвязать сайт от Telegram-канала. Раньше все посты на сайте соответствовали постам Телеги, и единственной возможностью обновить сайт было сделать выгрузку из ТГ. Теперь все посты канала (и старые, и новые) лежат у меня локально, и я их могу пулять на сайт по API. Соответственно, могу их массово анализировать и редактировать. И если (ну или когда 🙂) мой сайт на WordPress взломают, я смогу его довольно оперативно переподнять, т.к. какой-то ценности в базе на хостинге нет - это только зеркало.

Мартовский "В тренде VM": и снова уязвимости только в продуктах Microsoft

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

Мартовский В тренде VM: и снова уязвимости только в продуктах Microsoft

Мартовский "В тренде VM": и снова уязвимости только в продуктах Microsoft. Представляю традиционную ежемесячную подборку трендовых уязвимостей по версии Positive Technologies. Как и в феврале, она получилась весьма компактной и моновендорной.

🗞 Пост на Хабре
🗒 Дайджест на сайте PT

Все четыре уязвимости из февральского Microsoft Patch Tuesday и все с признаками активной эксплуатации:

🔻 RCE - Windows Shell (CVE-2026-21510)
🔻 RCE - Microsoft Word (CVE-2026-21514)

💬 Microsoft классифицировали две уязвимости выше как Security Feature Bypass, однако фактически это Remote Code Execution.

🔻 EoP - Windows Remote Desktop Services (CVE-2026-21533)
🔻 EoP - Desktop Window Manager (CVE-2026-21519)

🟥 Полный список трендовых уязвимостей смотрите на портале

Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1

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

Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1
Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1

Коллеги из R-Vision представили на днях новую версию системы управления уязвимостями R‑Vision VM 6.1. Резюме маркетологов R-Vision: "в релизе особое внимание было уделено тому, что важно в ежедневной работе: ускорении поиска уязвимостей, гибкой приоритизации и автоматизации рутинных процессов".

Подробности и демо, видимо, стоит ожидать на вебинаре 24 марта и на конференции R‑EVOlution 9 апреля.

В пресс-релизе R-Vision сделали акцент на следующие фичи:

🎯 Поиск уязвимостей без повторного сканирования "Ретроспективный аудит". Представляется как ключевое нововведение версии. Механизм позволяет выявлять уязвимости на основе ранее собранных данных, без запуска повторного сканирования. Фича опциональная. Можно настроить для отдельных хостов, групп хостов или для всех хостов. Запускается по триггерам - обновление базы (сразу пересчитывается по всем указанным целям), по расписанию или вручную.

С технической точки зрения здесь речь идёт о повторной корреляции уже собранных атрибутов активов (например, CPE, версии ПО, установленные пакеты, баннеры сервисов, результаты аутентифицированных проверок, конфигурационные артефакты) с обновлённой базой уязвимостей (в случае R-Vision речь, видимо, идёт о правилах детектирования уязвимостей на OVAL-like языке). За счёт того, что сбор актуальных данных о хосте не производится, новые уязвимости могут быть выявлены практически мгновенно, без нагрузки на сеть и хосты.

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

🧠 Графический конструктор расчёта рейтинга уязвимостей. Фича позволяет настраивать формулу приоритизации уязвимостей прямо в интерфейсе, используя атрибуты уязвимости, оборудования или групп ИТ-активов. Формула может учитывать различные типы данных (числовые, текстовые и справочники), что позволяет гибко адаптировать расчёт рейтинга под особенности конкретной ИТ-инфраструктуры.

Пример формулы для расчёта рейтинга уязвимости:

round((mean({calculation:calculate_cvss}) * (mean({calculation:calculate_k}) + mean({calculation:calculate_l}) + mean({calculation:calculate_p})) *
(mean({calculation:calculate_lat}) + mean({calculation:calculate_limp}))) * 10) / 10

Доступны преднастроенные варианты, включая основанный на Методике оценки уровня критичности уязвимостей (ФСТЭК 30.06.2025).

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

⚙️ Новый механизм политик управления активами и уязвимостями. Он позволяет задавать правила, которые автоматически срабатывают при наступлении заданных условий (по событию или по расписанию). Заявляется, что политики могут изменять атрибуты любых объектов системы или выполнять нужные действия: например, создавать задачу на устранение уязвимости при ее появлении, менять статус актива при обновлении данных или автоматически переводить уязвимость в нужную категорию на основании ее параметров. Поддерживается работа со всеми полями объектов. Это позволяет реализовывать сложные пользовательские сценарии – как в части управления уязвимостями, так и при построении ресурсно-сервисных моделей активов.

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

📂 Сканирование групп IT‑активов. Теперь группы IT‑активов можно использовать в задачи сканирования (как в списке целей, так и в исключениях). Состав таких групп может автоматически изменяться, что позволяет использовать одну задачу для актуальных групп активов и упрощает организацию процесса сканирования. Пример групп активов со скриншота: "Критичные устройства", "Критический ГИТ". Сканирование выполняется по IP или FQDN хоста.

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

📊 Улучшение информативности карточки задачи сканирования. Туда добавили статистику выполнения, отображение прогресса и ошибок подключения или сбора данных, что упрощает диагностику и контроль хода сканирования.

На последнем скриншоте можем видеть историю запусков. Для запуска показывается статус (завершён/отменён), статистику выполнения сканирования по целям, четырёхсегментный индикатор для статуса сканирования каждого таргета. Довольно симпатично. 🙂

⏱️ Настройка работы агентного сканирования. Появилось настраиваемое расписание, позволяющее задавать периодичность и время сбора данных.

Это должно помогать оптимизировать нагрузку на сеть и хосты. Интересно, как обрабатываются ситуации, когда синхронизация агента с сервером по каким-то причинам невозможна. Агент будет ждать следующего запуска по расписанию или выполнит синхронизацию ASAP?

📊 Улучшение информативности интерфейса. Добавлены полноэкранные карточки оборудования и уязвимостей, расширен набор отображаемых параметров, поддерживается перевод полей уязвимостей на русский язык, улучшены фильтры и представление данных.

В целом, по описанию все фичи выглядят интересно. Ждём демо. 🙂