Архив рубрики: Уязвимость

Распишу по поводу "карты достижимости" в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинаре

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

Распишу по поводу карты достижимости в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинареРаспишу по поводу карты достижимости в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинареРаспишу по поводу карты достижимости в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинареРаспишу по поводу карты достижимости в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинареРаспишу по поводу карты достижимости в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинаре

Распишу по поводу "карты достижимости" в Security Vision VM, которую коллеги из Security Vision зарелизили в январе и показали вживую на прошлой неделе на вебинаре. Скриншоты я делал с трансляции, поэтому извините за качество. 🤷‍♂️ Апскейлер не особо помог, но основное там вроде видно. 🙂

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

Информация для построения карты сети берётся из результатов активного сканирования (инвентаризации) хостов и сетевых устройств. При построении используются собранные таблицы маршрутизации, сетевые службы, порты, протоколы, сетевые интерфейсы. Чем полнее сканируете инфру, тем адекватнее будет карта.

Критичность активов может как задаваться вручную на странице актива (уровень критичности и флаг "стратегического" актива - аналог "целевого" из методологии РКН), так и определяться автоматически (есть ли у актива доступ в Интернет, есть ли у актива привязка к стратегическому активу).

При построении графов достижимости поиск направлен в сторону стратегических активов.

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

🔴 Красные связи показывают достижимость атаки до критических активов через эксплуатацию уязвимостей на хостах.

🟡 Жёлтые связи показывают прерывание атаки на определенном активе и невозможность развития атаки по данному маршруту.

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

Ок, это всё красиво. Но как это использовать для приоритизации активов и уязвимостей? 🤔

В правой части дашбордов есть таблички с ТОПом активов и их уязвимостей с параметром "степень участия". Этот параметр некоторым образом проприетарно высчитывается и характеризует степень участия актива или уязвимости в потенциальной атаке. Соответственно, следует в первую очередь обращать внимание на активы и уязвимости с максимальной степенью участия. Так на скриншоте можно видеть публично доступный Linux хост с Confluence (с.у. 0,5) уязвимый к CVE-2023-22527 (с.у. 0,5) и виндовую RCE CVE-2024-38063 (с.у. 1).

В общем, такая вот новая функциональность. Это, конечно, пока не тянет на полноценное моделирование Attack Paths, т.к.

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

🔹 Это всё про уязвимости софта (CVE), а не про экспозиции. Те же проблемы с учётками и мисконфигурации никак не учитываются, но коллеги из Security Vision обещают добавить их на граф уже в ближайших релизах.

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

Продолжу разбирать "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-специалист должен понимать ограничения используемых средств анализа защищённости и выбирать наиболее адекватные из них (а не самые дешёвые 😉).

Про уязвимость Remote Code Execution - Microsoft Word (CVE-2026-21514)

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

Про уязвимость Remote Code Execution - Microsoft Word (CVE-2026-21514)

Про уязвимость Remote Code Execution - Microsoft Word (CVE-2026-21514). Уязвимость из февральского Microsoft Patch Tuesday. Использование недоверенных входных данных при принятии решения, связанного с безопасностью (CWE-807), в Microsoft Office Word позволяет неавторизованному злоумышленнику обойти функции безопасности OLE при открытии зловредного файла. Уязвимость НЕ эксплуатируется при просмотре через Preview Pane.

👾 Microsoft сообщают об эксплуатации уязвимости в реальных атаках. Уязвимость в CISA KEV с 10 февраля.

💬 Microsoft классифицировали уязвимость как Security Feature Bypass, однако, учитывая, что эксплуатация таких уязвимостей приводит к выполнению произвольного кода, выглядит правильным классифицировать её как Remote Code Execution, по аналогии с активно эксплуатируемой уязвимостью CVE-2026-21509.

🛠 Публичных эксплоитов пока нет.

Смотрю подкаст коллег из 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.

Поделюсь впечатлениями от сегодняшнего вебинара про Security Vision VM

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

Поделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VM

Поделюсь впечатлениями от сегодняшнего вебинара про Security Vision VM. Вебинар назывался достаточно провокационно: "98% уязвимостей можно игнорировать? Как перестать чинить всё подряд и заняться реальными угрозами". Меня формулировки про 2% всегда триггерят. 😤 Я считаю, что фиксить нужно ВСЕ уязвимости (но с разным SLA) и, по возможности, безусловным патчингом.

Но, по правде сказать, на этом вебинаре и НЕ транслировали идею, что 98% уязвимостей можно игнорировать. Скорее, подробно демонстрировали возможности Security Vision VM (я наделал ~100 скринов 🔥) и говорили о необходимости приоритизированного устранения уязвимостей. 👌

Для этого Security Vision представили свою версию Трендовых Уязвимостей. Это уязвимости из CISA KEV ИЛИ с EPSS > 0,5. Всего у них получается ~1500 таких уязвимостей.

Мне, конечно, есть что сказать и про EPSS, и про CISA KEV. 🙄 Но как быстрое решение, как плейсхолдер - почему бы и нет. Это лучше, чем ничего. 👍

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

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

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

По поводу внесения питерской компании Operation Zero и связанных с ней лиц в американский санкционный список. Имхо, в этой длящейся истории со сливом и продажей восьми американских эксплойтов важно отделять главное от второстепенного. И главное в ней - признание США, что они целенаправленно разрабатывают кибероружие. Их оборонные подрядчики ресёрчат уязвимости и разрабатывают эксплоиты для наступательных киберопераций и кибершпионажа. Угадайте, против кого. 😏

🔻 Уязвимости - это не просто ошибки ПО, которые нужно отнести вендору за баунти/спасибо и CVE-шку. 🤤

🔻 Уязвимости - это стратегически важная информация, требующая внимания и регулирования. ⚔️

Наши заклятые партнёры это хорошо понимают. Не случайно утечку эксплоитов сам министр финансов комментирует. 😉

Хотелось бы, чтобы в России поскорее обратили внимание на трансграничный репортинг уязвимостей и приняли меры для усиления наступательного киберпотенциала страны. 🙏