Архив за месяц: Март 2026

Распишу по поводу "карты достижимости" в 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)

1 комментарий

Про уязвимость 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.

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