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

Инфосистемы Джет выложили "Результаты тестирования решений для управления уязвимостями" по новой версии методики (3.0)

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

Инфосистемы Джет выложили Результаты тестирования решений для управления уязвимостями по новой версии методики (3.0)

Инфосистемы Джет выложили "Результаты тестирования решений для управления уязвимостями" по новой версии методики (3.0). Тестировали следующие продукты:

🔸 MaxPatrol VM v. 2.8 (27.6)
🔸 SecurityVision VM v. 5.0.1773849508
🔸 ScanFactory v. 7.21.9
🔸 R-Vision VM v. 6.2
🔸 AlphaSense v. 4.57.08.04

В отличие от тестирования по второй версии методики, здесь отсутствуют RedCheck и Vulns io VM. Возможно их добавят позже.

Оценка проводилась по 12 группам требований:

⚙️ Нефункциональные требования. Автоматическое и оффлайн обновление базы уязвимостей, открытый доступ к базе, централизованное управление, агентское сканирование и работа с хостами, поддержка изолированных сегментов и распределенной установки компонентов, мультиязычность, мультитенантность, а также соответствие требованиям ФСТЭК и включение в реестр отечественного ПО.

📱 Мобильный сканер. Наличие портативного (мобильного) сканера с возможностью переноса результатов в основную инсталляцию и формирования отчетов.

🗺️ Управление активами. Интерактивная карта сети, управление активами (динамические группы, поиск, карточки), скоринг и дедупликация активов, тегирование, хранение истории изменений, патч-менеджмент и выполнение административных команд на активах.

🧠 Настройка общих правил и логики системы. Управление задачами на устранение уязвимостей с назначением ответственных и SLA, сквозной поиск, фильтрация и сортировка по активам и уязвимостям, настройка оповещений о сканированиях, патч-менеджмент и автоматическое обновление атрибутов уязвимостей (критичности, сроков устранения и рекомендаций по устранению).

📊 Функционал визуализации и отчетности. Визуализация данных через настраиваемые виджеты и дашборды, создание и планирование отчетов, расширенная кастомизация интерфейса и объектов.

💻 Поддерживаемые типы активов для сканирования. Поддержка сканирования операционных систем (Windows, Linux и отечественных ОС), сетевого и серверного оборудования, СУБД и серверного ПО, а также поддержка периферийных устройств, промышленных систем (ICS/SCADA) и контейнеров.

🔗 Возможности интеграции. Документированный API с управлением доступом через ключи, встроенный мониторинг работоспособности (health-check) и интеграции с внешними системами мониторинга, поддержка доменной аутентификации, интеграции с Service Desk/ITSM и с SIEM, получение данных об активах из смежных систем и отправка оповещений.

🛡️ Управление сканированием и уязвимостями. Кастомизация карточки и тегирование уязвимостей, планирование и управление сканированиями (расписания, профили, ретроскан, исключения, технологические окна, пауза, клонирование), настройка правил и параметров сканирования, проверка доступности и учетных записей, в том числе брутфорс с пользовательскими словарями и несколькими типами учетных записей, управление исключениями, прогресс в реальном времени, расширенная работа с уязвимостями (CVE/CWE/БДУ, CVSS v2–v4 и кастомные метрики, скоринг, дедупликация, эксплуатируемость, вероятность использования, наличие эксплойтов, путь атаки, трендовость), а также рекомендации, внешние ссылки и методики ФСТЭК и НКЦКИ, плюс оповещения о событиях системы.

📏 Оценка соответствия. Проверка активов на соответствие стандартам безопасной конфигурации, создание пользовательских проверок и требований через конструктор, точечная переоценка активов, рекомендации по устранению несоответствий, ведение истории оценок и встроенное сравнение результатов.

🌐 Сканирование веб-ресурсов. Аутентификация в веб-приложениях, сканирование веб-ресурсов (поиск поддоменов, скрытых файлов и директорий), режимы имитации и активной атаки, а также обнаружение широкого спектра уязвимостей (инъекции, CSRF, загрузка файлов и доступ к ФС, клиентские атаки, редиректы, слабая криптография, небезопасные security headers, утечки информации, cookie и сессионные уязвимости, memory corruption).

🔐 Безопасность. Настраиваемая ролевая модель, управление парольной политикой (сложность, история, минимальная длина, срок действия), блокировка учетных записей после неудачных попыток входа, шифрование критичных данных с поддержкой пользовательских ключей и создание/восстановление из резервных копий.

⚡ Производительность и эффективность. Скорость обновления базы уязвимостей (от появления в публичных источниках до добавления в сканер), настройка интенсивности сканирования через веб-интерфейс, поддержка геораспределенных филиалов и мультитенантности, а также возможность выбора нескольких модулей сканирования в одной задаче.

Возможные значения для каждого требования: ✅ Да, ❌ Нет, Частично. За исключением "Производительность и эффективность" → "Скорость добавления новых уязвимостей в базу уязвимостей решения…", где указывается значение в часах. По некоторым требованиям доступны 💬 комментарии вендоров.

Работа была проделана, вне всяких сомнений, большая и основательная. 🔥 Но, как и в случае тестирования по первой версии методики, мне не хватает оценки качества детектирования. Большая часть этой функциональности скрывается за пунктом "Поддержка сканирования ОС: Windows Server, Windows, AlmaLinux, Ubuntu, Debian" с галочкой у всех вендоров и без каких-либо комментариев. А ведь там самое интересное, ради чего, собственно, пользователи и покупают САЗы. Очень хотелось бы гораздо большей детализации поддерживаемых типов активов и подробного сравнения результатов детектирования на стендах с детализацией до конкретных CVE-шек, чтобы была видна разница в реализованной логике детектирования. Возможно, когда-нибудь и это сделают. 🙂

Что если стоимость страхования киберрисков для компании определялась бы не по анкетам, а по реальному состоянию защищённости инфраструктуры?

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

Что если стоимость страхования киберрисков для компании определялась бы не по анкетам, а по реальному состоянию защищённости инфраструктуры?

Что если стоимость страхования киберрисков для компании определялась бы не по анкетам, а по реальному состоянию защищённости инфраструктуры? В блоге Qualys сегодня появилась интересная новость. Они совместно с компанией Converge, специализирующейся на киберстраховании, запускают совместное решение по андеррайтингу киберрисков в реальном времени. Андеррайтинг - это процесс, в котором страховая компания оценивает риск и решает: страховать компанию или нет, сколько будет стоить полис, какие ограничения будут в страховке (например, что покрывается, а что нет). Так вот, большинство андеррайтеров по-прежнему полагаются статические анкеты самоотчётности (self-reported static questionnaires) - документы, которые долго заполняются, отличаются от организации к организации и по сути не отражают реальное состояние безопасности инфраструктуры организации. В результате страховые премии (сумма, которую компания платит за страховку, обычно раз в год) формируются на основе предположений о практиках безопасности организации.

Получается, что руководители ИБ инвестируют значительные бюджеты и усилия в снижение риска. Они внедряют управление уязвимостями. Обеспечивают управление патчами. Мониторят конечные точки. А затем при продлении полиса киберстрахования снова заполняют ту же статическую анкету, что и 12 месяцев назад, вручную, по памяти, без связи с проверенными данными, уже находящимися в их платформе безопасности. Этот разрыв в данных стоит организациям денег. Андеррайтеры, работая с неполной информацией, оценивают риск консервативно. Организации с действительно сильной программой безопасности фактически субсидируют более слабые.

Для решения проблемы Qualys сделали Converge Connect Insurance Report (CCIR), который фиксирует данные по ИБ-решениям Qualys, используемым в организации:

🔹 Enterprise TruRisk Management (ETM)
🔹 Vulnerability Management, Detection & Response (VMDR)
🔹 Возможности управления патчами TruRisk Eliminate
🔹 Endpoint Detection & Response (EDR)

Этот отчёт передаётся в Converge через назначенного брокера (Symphony Risk Solutions), дополняя традиционную анкету и снижая количество вопросов в процессе страхования. Андеррайтеры получают проверенные данные. Организации получают премию, отражающую реальный уровень киберриска.

Предложение доступно клиентам Qualys в США в большинстве отраслей с выручкой до 5 млрд долларов. Минимальное требование - активная подписка на VMDR.

Интерес Qualys в этой инициативе довольно понятный и многослойный.

1️⃣ Они усиливают ценность своих продуктов. Раньше Qualys продавал инструменты для управления уязвимостями, патчами и endpoint-ами как способ снизить киберриски. Теперь это подаётся гораздо сильнее: не просто "вы снижаете риск", а "вы потенциально снижаете стоимость киберстраховки". Для бизнеса это уже более осязаемый финансовый эффект.

2️⃣ Это стимулирует расширение использования их экосистемы. В программе участвуют только клиенты с определёнными продуктами Qualys. Чем больше модулей используется, тем полнее данные, тем качественнее отчёт для страховщика и тем выше шанс на снижение страховой премии. Это классический механизм увеличения проникновения внутри клиента.

3️⃣ Появляется эффект привязки к платформе. Если страховая начинает учитывать данные Qualys при оценке риска и расчёте цены, переход на другого вендора становится сложнее. Исторические данные, отчёты и привычный формат оценки риска оказываются завязаны на одну систему.

4️⃣ И наконец, Qualys фактически расширяет своё присутствие за пределы классического рынка кибербезопасности. Они заходят в смежную область - киберстрахование и управление финансовым риском. В перспективе это превращает их не просто в security-вендора, а в один из ключевых источников данных для оценки киберрисков на рынке.

Конкурирующие с Qualys вендоры могут делать то же самое, ведь у них тоже есть данные о состоянии безопасности, на основе которых можно строить риск-отчёты для страховых. Но ключевой вопрос не в наличии данных, а в доверии и стандартизации: страховые должны признавать эти метрики объективными и использовать их в андеррайтинге.

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

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

В этот четверг, 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 тоже расскажем и покажем продукты, которые его реализуют. 😉

Продолжу разбирать "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"

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

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

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

Как работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимости

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

Как работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимостиКак работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимости

Как работать с уязвимостями своей инфраструктуры в SBER X-TI? Для этого в облако SBER X-TI нужно отправлять данные инвентаризации активов, по которым будут рассчитаны уязвимости. Есть готовые интеграции с Security Vision или R-Vision (+ компании предоставили урезанные бесплатные версии продуктов только для инвентаризации), BiZone TDR и GRC, Ansible.

Для уязвимостей есть признаки эксплуатации вживую и публичные эксплоиты, есть расчёт критичности по методике ФСТЭК, есть проверенные патчи (они там появляются раньше и их больше, чем на БДУ ФСТЭК), можно заводить задачи на устранение с автоматическим закрытием при перескане.

Напоминает зародыш российского "Qualys-а". 🤔 Не хватает только облачных агентов и апплаенсов. И неплохо было бы загружать не только инвентаризацию, но и уязвимости продетектированные сторонним сканерами. 😉

Учитывая, что это всё бесплатно, всему нашему VM-рынку стоит обратить внимание и задуматься, чем это крыть.

Если есть ИБ-бюджет, потрать его в первую очередь на Vulnerability Management и Hardening

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

Если есть ИБ-бюджет, потрать его в первую очередь на Vulnerability Management и Hardening

Если есть ИБ-бюджет, потрать его в первую очередь на Vulnerability Management и Hardening. 😉 По поводу этой картинки Mads Bundgaard Nielsen-а, о которой писали Александр Редчиц и Алексей Лукацкий, у меня вопросов нет. Ну, во всяком случае, по моей части. 😏

Видим у Vulnerability Management-а и Compliance Management-а (Наrdening-а) очень высокую эффективность при средней цене. И это должен быть первый приорититет у CISO. ⚡️

После Firewall-а. 🙄 Тут спорно, но пусть будет так. Без NGFW заниматься безопасностью действительно не сладко.

В общем, одобряю картинку. 🙂👍