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

Продолжу разбирать "10 неудобных вопросов Product Manager-у по VM" из подкаста коллег из R-Vision

Продолжу разбирать 10 неудобных вопросов Product Manager-у по VM из подкаста коллег из R-Vision

Продолжу разбирать "10 неудобных вопросов Product Manager-у по VM" из подкаста коллег из R-Vision.

Вопрос 2: Вы можете гарантировать, что в вашем сканере уязвимостей не будет фолзов?

💬 Андрей Селиванов сначала пошутил, что можно гарантировать отсутствие фолзов, если просто не проводить сканирование. 😏 Далее сказал, что фолзы (некорректные детекты каких-то уязвимостей) есть в абсолютно любом решении. Причин для этого может быть масса: от некорректной информации по детектированию уязвимости в источнике данных об уязвимости (например, бюллетене RHSA вендора Red Hat или на странице с описанием уязвимости Microsoft) до ошибок при написании правил детектирования на стороне VM-вендора. Важны два параметра: процент допустимых фолзов в решении VM-вендора и то, как быстро VM-вендор их устраняет (принимая от клиентов через форму обратной связи).

#️⃣ С этим тоже не поспоришь. Но я бы посмотрел несколько шире. Фолзы - это не только про то, что какие-то конкретные правила детектирования были реализованы некорректно. Хотя, безусловно, и это тоже, и хотелось бы, чтобы такие проблемы VM-вендор ловил самостоятельно, а не только после того, как их зарепортят клиенты. 😉 Это ещё и про зрелое восприятие возможностей VM-продукта и зрелое позиционирование VM-продукта вендором.

🔹 Если сканер не детектирует какие-то уязвимости в инфраструктуре, потому что не поддерживает те или иные продукты или способы установки, это со стороны клиента может выглядеть как false negative. А может как вполне осознаваемые ограничения детектирования VM-продукта.

🔹 И с другой стороны, то, что упомянул вскользь Андрей "многое зависит от окружения, от специфических условий", когда сканер детектирует уязвимости в библиотеке, которая по факту не используется, это может восприниматься со стороны клиента как жуткие false positive ошибки. А может как особенность детектирования "потенциальных" уязвимостей сканером.

Тут, наверное, хотелось бы, чтобы мы (как VM-комьюнити) отходили от восприятия любых средств анализа защищённости как волшебных оракулов, которые выдадут все 100% имеющихся уязвимостей в инфраструктуре. Конечно же, нет. 🤷‍♂️

Детектирование всех уязвимостей конкретной инфраструктуры - это сложная задача. За которую ответственен в первую очередь VM-специалист. И VM-специалист должен понимать ограничения используемых средств анализа защищённости и выбирать наиболее адекватные из них (а не самые дешёвые 😉).

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) "10 неудобных вопросов Product Manager-у по VM"

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) 10 неудобных вопросов Product Manager-у по VM

Смотрю подкаст коллег из R-Vision Андрея Селиванова (руководитель продукта R-Vision VM) и Антона Исаева (лидер продуктовой практики R-Vision SIEM/VM) "10 неудобных вопросов Product Manager-у по VM". Естественно, обсуждение шло в контексте решения R-Vision VM. Интересный формат и подборка вопросов. 🔥 Собираюсь их постепенно разобрать и добавить свои комментарии. 😉

Вопрос 1: Класс Vulnerability Management решений - это маркетинговая обёртка сканеров уязвимостей или за этим есть какие-то дополнительные технологии?

💬 Андрей Селиванов ответил в духе, что VM-решения - эволюционное развитие сканеров уязвимостей, потребность в которых возникла с увеличением количества активов (сказал, что у них есть клиент с 300 000 конечных точек и сотней миллионов уязвимостей) и увеличением разнообразия типов активов. Все уязвимости на этих активах необходимо эффективно детектировать, приоритизировать и ставить задачи на устранение. С простым сканером уязвимостей с таким объёмом справляться сложно, требуется более функциональное решение. "Но сканер - это то, по чему встречают решение в любом пилоте и у любого клиента". Важно, насколько качественно выявляются уязвимости, насколько широкое покрытие. "Если у тебя не будет нормального сканера, называться полноценным VM-решением - ну такое себе".

#️⃣ В целом, согласен со сказанным. Особенно в части качества детектирования. 👍 Единственное я бы выделил такие формальные признаки сканера уязвимостей и VM-решения: если средство анализа защищённости (САЗ) работает в парадигме отдельных сканов - это сканер уязвимостей. Классический пример - Nessus. А если САЗ хранит картину текущего состояния всей инфраструктуры (активов и уязвимостей на них), позволяет делать выборки по уязвимостям, делать приоритизацию уязвимостей, заводить и отслеживать задачи на устранение (через встроенную тикетницу или через интеграции) и производить прочую высокоуровневую обработку, то это уже решение класса Vulnerability Management. Потому что это решение реализует внутри себя Vulnerability Management процесс. Ну или, во всяком случае, вендор решения это декларирует и к этому стремится. 😉

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

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

🔹 В свою очередь VM-решение может лишь формально реализовывать заявленную функциональность и, к примеру, не справляться с реальной нагрузкой (особенно если его навайбкодили за выходные 😉). VM-решение вообще может быть опенсурсным проектом, типа Faraday Security или DefectDojo, и стоить (ну, в теории 😏) 0 руб.

Так что маркетинговые категории мало чего значат на самом деле. Нужно смотреть в суть.

Мои коллеги по PT ESC зафиксировали первую фишинговую кампанию с использованием уязвимости Remote Code Execution - Microsoft Office (CVE-2026-21509), направленную на российские организации

Мои коллеги по PT ESC зафиксировали первую фишинговую кампанию с использованием уязвимости Remote Code Execution - Microsoft Office (CVE-2026-21509), направленную на российские организации

Мои коллеги по PT ESC зафиксировали первую фишинговую кампанию с использованием уязвимости Remote Code Execution - Microsoft Office (CVE-2026-21509), направленную на российские организации. Атакующие, с высокой вероятностью связанные с группировкой BoTeam, рассылают зловредные RTF-файлы, оформленные как переписка с регулятором Ространснадзор ("Акт проверки транспортного средства", "Форма письменных пояснений").

Уязвимость CVE-2026-21509 позволяет обойти функции безопасности OLE при открытии зловредного документа Microsoft Office, выполнить HTTPS-запрос к серверу злоумышленников и скомпрометировать десктоп жертвы в ходе многоступенчатой атаки.

Уязвимость была экстренно исправлена 26 января вне регулярных Microsoft Patch Tuesday. Входит в списки трендовых уязвимостей Positive Technologies и R-Vision.

Посмотрел хабропост с трендовыми уязвимостями за январь по версии R-Vision, опубликованный 5 февраля

Посмотрел хабропост с трендовыми уязвимостями за январь по версии R-Vision, опубликованный 5 февраля

Посмотрел хабропост с трендовыми уязвимостями за январь по версии R-Vision, опубликованный 5 февраля. Всего три уязвимости. Две из них в продуктах Microsoft также попали в список трендовых от Positive Technologies:

🔻 RCE - Microsoft Office (CVE-2026-21509)
🔻 InfDisc - Desktop Window Manager (CVE-2026-20805)

Ещё одну уязвимость относят к трендовым только R-Vision:

🔻 AuthBypass - GNU Inetutils Telnet (CVE-2026-24061)

Уязвимость критичная. 💯 Однако, если в 2026 году у вас в проде используется Telnet, это должно вызывать вопросики само по себе. 😉 Также важно понимать, что уязвим не Telnet как протокол, а реализация Telnet-сервера в GNU Inetutils, альтернативных реализаций множество. Есть данные, что в Рунете реально подвержены уязвимости всего около пяти хостов. Так что трендовость под вопросом, но если у вас эта уязвимость детектируется, безусловно, устраняйте.

Прочитал статью "NVD больше не успевает за реальностью: взгляд R-Vision на пересмотр роли NIST"

Прочитал статью NVD больше не успевает за реальностью: взгляд R-Vision на пересмотр роли NIST

Прочитал статью "NVD больше не успевает за реальностью: взгляд R-Vision на пересмотр роли NIST". Очередная рефлексия на статью CYBERSECURITY DIVE про то, что у NIST-а лапки. 🙂 Имхо, ключевой тезис в статье R-Vision вот этот:

"Для нас качество базы измеряется не количеством CVE, а:

- скоростью реакции;
- полнотой покрытия реальных технологий;
- способностью адаптации под инфраструктуры заказчиков."

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

Но с другой стороны, сравнение баз VM-решений пересечением наборов CVE-идентификаторов всё ещё позволяет эффективно подсвечивать разницу в ТЕКУЩИХ возможностях детектирования и, при необходимости, обсуждать её с VM-вендорами. 😏 Аналогично можно сравниваться и по БДУ-идентификаторам. 😉

Пришёл новогодний подарок от коллег из R-Vision

Пришёл новогодний подарок от коллег из R-Vision

Пришёл новогодний подарок от коллег из R-Vision. 🙂 Внутри, помимо поздравительной открытки:

🔹 Бутылка отечественного вина. Мы алкоголь не употребляем, но это не беда - передарим. 😉

🔹 Сертификат на шоу Luminar-x Elements. Вот это круто, на ВДНХ часто бываем, обязательно заценим. 👍

Спасибо большое, R-Vision! С наступающим! 🎄

Две недели назад TAdviser выпустили "Карту российского рынка информационной безопасности 2025"

Две недели назад TAdviser выпустили Карту российского рынка информационной безопасности 2025

Две недели назад TAdviser выпустили "Карту российского рынка информационной безопасности 2025". В отличие от прошлого года, на ней появилось "Управление Уязвимостями". Прогресс. 👍🙂

🔹 Управление Уязвимостями объединили с решениями по Харденингу. Поэтому в группу попали Spacebit, Кауч и ЛИНЗА, которые (пока) не про уязвимости. Всего 15 вендоров.

🔹 Осталась группа Средств Анализа Защищённости, совмещённая с DevSecOps. В ней 22 вендора. С прошлого года убрали (5): Фродэкс (Vulns io), BIFIT, RED, Crosstech, Pentestit. Добавили (6): VK Cloud, Sber Tech, Yandex, УЦСБ, Axiom JDK, Luntry. Переименовали (1): Profiscope в CodeScoring.