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

Коллеги из 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?

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

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

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

Сегодня покрутил идею SOVA - проекта упрощённого аналога OVAL, о котором я писал в октябре

Сегодня покрутил идею SOVA - проекта упрощённого аналога OVAL, о котором я писал в октябре

Сегодня покрутил идею SOVA - проекта упрощённого аналога OVAL, о котором я писал в октябре. В итоге набросал тестовый дефинишен, описывающий проверку отключения аутентификации по паролю на SSH-сервере.

Как можно видеть, здесь комбинация двух тестов, выполняющих bash-скрипты, статусы которых объединяются по И. Всё сразу наглядно читается и, как я подозреваю, такие дефинишены будет очень просто генерить нейронкой по тексту из руководств по харденингу а-ля CIS Benchmarks. 😉

Проект завёл на платформе GitVerse от Сбера. Буду потихоньку его вайб-кодить в свободное время. 🙂 GitVerse, кстати, вполне норм. На мой неискушённый взгляд, ничем GitHub-у не уступает, можно пользоваться. 😉

Ходили сегодня в Музейную фабрику пастилы

Ходили сегодня в Музейную фабрику пастилы

Ходили сегодня в Музейную фабрику пастилы. Среди прочих интересных и вкусных активностей перед нами разыграли небольшую зарисовку по рассказу Надежды Тэффи "Сам". Рассказ о том, как отец семейства в целях экономии решил САМ делать пастилу, а не покупать в магазине. Вконец измучился, а получилось малосъедобно и дороже покупной.

У меня это срезонировало с вопросом об in-house разработке средства детектирования уязвимостей, который недавно поднимал Андрей Дугин.

VM-вендоры продают лицензии и имеют возможность использовать эти средства для развития решения и расширения команды разработки. А in-house сканер так и будут пилить 1,5 программиста в свободное от других задач время. До момента, как кто-то из них уволится, и код станет неподдерживаемым легаси. 🤷‍♂️ Ладно ещё делать утилиту для детекта уязвимостей в конкретной системе, с которой не работают коммерческие решения. Но пилить своими силами универсальный сканер уязвимостей - задача амбициозная до безумия.

В отпуске поразмышлял о том, как могла бы выглядеть более жизнеспособная альтернатива OVAL-у - проект SOVA

В отпуске поразмышлял о том, как могла бы выглядеть более жизнеспособная альтернатива OVAL-у - проект SOVA

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

Пока основные идеи такие:

📃 Отказаться от XML в пользу JSON, с которым проще работать и автоматически, и вручную.

⚙️ Сохранить основную фишку OVAL-а - статусы дефинишенов определять комбинацией статусов тестов или других дефинишенов.

🧪 Типы тестов вынести из спецификации языка и упростить их заведение. Вплоть до возможности создания тестов с выполнением произвольного bash-скрипта на хосте или выполнением веб-запросов. 😈

🧭 Описание параметров тестов (объектов и стейтов) хранить прямо в блоке с логикой детектирования статуса дефинишена. Тогда не придётся бегать по разным разделам документа, чтобы понять фактическую логику детектирования. И это важнее некоторой избыточности описания. 😉

На сайте Anti-Malware вышла статья Николая Рягина из R-Vision "Как отличить качественную базу уязвимостей от справочника CVE"

На сайте Anti-Malware вышла статья Николая Рягина из R-Vision Как отличить качественную базу уязвимостей от справочника CVE

На сайте Anti-Malware вышла статья Николая Рягина из R-Vision "Как отличить качественную базу уязвимостей от справочника CVE". Мне статья очень понравилась, в лайв-канале я сделал краткую выжимку.

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

1. 📦 Полнота покрытия продуктов
2. 🔄 Частота выпуска обновлений правил детектирования
3. 🌐 Использование источников данных об уязвимостях
4. ✅ Верификация правил детектирования
5. 🧪 Тестирование процесса детектирования
6. 🔍 Прозрачность логики детектирования
7. ⚡️ Скорость исправления ошибок детектирования
8. 🛠 Адаптируемость детектирования под заказчика
9. 📖 Полнота информации по устранению уязвимостей

💡 Имхо, эти параметры могут стать основой для открытого фреймворка, используемого как самими VM-вендорами для самооценки своих решений и процессов, так и клиентами при выборе VM-решений.

Детектировать нужно все уязвимости!

Детектировать нужно все уязвимости!

Детектировать нужно все уязвимости! Частенько натыкаюсь на мнение, что основательный подход к построению VM процесса, например по БОСПУУ, приведёт к тому, что продетектированных в организации уязвимостей будет слишком много, "IT с такими объёмами не справится". А раз так, то не стоит и начинать. 🫠

Мой ответ на это:

🔻 Прежде всего следует поставить вопрос, почему устранять уязвимости (~обновлять системы) является настолько мучительной задачей для IT. Скорее всего, это свидетельство архитектурных проблем, препятствующих внедрению базовых процессов кибергигиены. Невозможность устранять уязвимости - только следствие. 🌝

🔻 Выявлять нужно все уязвимости, но устранять их следует приоритизированно. В первую очередь следует устранять уязвимости, эксплуатация которых наиболее проста и выгодна злоумышленникам. А как это понять? Для этого, по-хорошему, необходимо формировать потенциальные пути атак (attack paths), производить их оценку и приоритизацию. И для этого есть решения. 😉