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

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT

2 комментария

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT. Когда мы с коллегами готовили вопросы итогового тестирования для очередного потока курса "Управление Уязвимостями: от теории к практике", один из предложенных вопросов там формулировался примерно так:

Обнаружена критическая уязвимость в сервисе на периметре, который выполняет некоторую бизнес-функцию. Признаков эксплуатации нет. Вендор рекомендует срочно обновить ПО и применить защитные меры. По регламенту устранение уязвимости должно быть выполнено за 24 часа. Руководитель ИТ просит продлить срок до 72 часов, так как команда занята другим релизом. Какое решение будет наиболее правильным с точки зрения процесса VM?

🔹 Предложить внедрить компенсирующие меры в компромиссный срок.
🔹 Апеллировать к регламенту и требовать перенести релиз, эскалируя вопрос руководству.
🔹 Согласиться на 72 часа из-за отсутствия признаков эксплуатации.
🔹 Изучить возможность эксплуатации уязвимости, совместно с SOC срочно ограничить доступ к уязвимому сервису.

Какой ответ считается правильным в тесте, я не скажу. 😉 Но ситуация более чем типичная и на ней, как мне кажется, хорошо демонстрируется правильный VM-ный майндсет.

Когда говорят про VM, обычно подчеркивают необходимость искать компромиссы и выстраивать конструктивное взаимодействие с командами, чтобы вместе достигать общих целей. И это во многом действительно так. Специалистам по VM важно доносить до владельцев систем критичность выявленных проблем и объяснять связанные с ними риски. Однако на другой стороне (в IT и бизнесе) тоже работают компетентные люди, которые действуют в рамках собственных приоритетов. Устранение уязвимостей приоритетной задачей для них, как правило, не является. Поэтому переносы сроков устранения под разными предлогами или даже отказы от устранения уязвимостей - явление вполне обыденное. 🤷‍♂️

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

При реализации такого сценария вопрос уже может стоять не только об увольнении, но и о гораздо более серьезных последствиях. Вплоть до уголовной ответственности. Особенно если вы работаете в государственных организациях, на объектах КИИ или с системно значимыми сервисами. Прежние договоренности с вашими коллегами в этот момент в значительной степени обнулятся. Начнется судорожный поиск виноватых: кто отвечал за устранение злополучной уязвимости и кто недостаточно хорошо выполнил свою работу. И будьте уверены, что ваши коллеги из IT и бизнеса будут говорить примерно следующее:

"Вы VM-щики, вы должны были разбираться с этой уязвимостью. Мы в этом не специалисты и не обязаны в этом разбираться. Мы вообще не знали, что эту уязвимость нужно было устранять."

Попробуйте мысленно перенестись еще на один шаг вперед - представьте, что вы сидите на допросе, в весьма некомфортных условиях, вам в глаза светит лампа, и вы понимаете, что в своей работе что-то делали не так. Задайте себе вопрос: "Что помогло бы мне в этой ситуации? Что нужно было сделать, чтобы лично ко мне, VM-щику, не возникло вопросов?"

🔻 Если ваши коллеги из IT и/или бизнеса должны были устранять такого рода уязвимости, значит, должен быть документ, в котором прописано, какие типы уязвимостей они устраняют и в какие сроки. Эти сроки должны быть заранее согласованы и зафиксированы. Этой бумажной частью работы кто-то должен методично заниматься.

🔻 Если вы раньше знали об этой уязвимости (детектировали её в рамках сканов), значит, нужно было донести эту информацию до ответственного за устранение так, чтобы это было неотказуемо. Что значит неотказуемо? Не устно, не через мессенджеры и даже не через почту. По этой уязвимости должна существовать задача на устранение, назначенная на конкретного исполнителя, с указанием крайнего срока. Да, этот срок может быть сложно выдержать в реальных условиях, но формально и по руководящим документам он должен быть установлен. С вашей стороны всё, что нужно, должно было вылететь. Если срок устранения не был выдержан, нужно было показать свое деятельное участие: что вы пытались эскалировать проблему. Возможно, попытки эскалации все равно были бы безуспешными, но эти попытки необходимо фиксировать.

🔻 Если вы раньше не знали об этой уязвимости (НЕ детектировали её в рамках сканов), возникает вопрос: почему? Не занимались планомерным покрытием инфраструктуры регулярными сканами? Вместо качественных средств детектирования использовали быстрые? 😉 Аргумент "мы сканировали, но сканер нам ничего не показал" будет выглядеть в рамках разбирательства весьма слабо. Оценка качества детектирования - ваша задача.

И так далее. Эти формальные меры могут повысить шансы, что в случае неприятного инцидента простого VM-щика не сделают крайним: не посадят и не уволят с волчьим билетом.

А когда все эти формальные шаги предприняты, можно уже говорить о более технических вещах: смотреть, какие уязвимости реально эксплуатируемы, а какие вроде как нет (в моменте), и активнее работать именно с теми, которые несут наибольшую опасность. Но, на мой взгляд, это должно иметь меньший приоритет, чем поддержание корректного формального процесса, который не стыдно показать регулятору на аудите. 😉

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

Так что склоняюсь скорее ко второму варианту. И там уж как пойдет. Получится пропушить устранение в нормативное время, отлично. 👍 Не получится пропушить, но инцидента в растянутый срок устранения не произойдет, тоже норм. 👌 Если злодеи все-таки успеют пробить периметр организации в растянутый срок устранения и это приведет к критичному инциденту - плохо. 😔 Но в этой ситуации будет что показать приехавшим разбираться людям в погонах и будет чем аргументировать, что VM-щик сделал все, что мог.

Дефолтный алгоритм такой: представьте, что вы на допросе по инциденту, случившемуся из-за эксплуатации уязвимости. Какие артефакты, по вашему мнению, могут помочь не присесть конкретно вам? 🙂 Обычно такой мысленный эксперимент подсказывает, чего вашему VM-ному процессу на самом деле не хватает. Те же VM-щики, которые всегда готовы на компромисс и не думают о последствиях для себя лично, имхо, рискуют оказаться в неожиданный момент кинутыми буквально всеми и с горячей картошкой в руках.

Коллеги из Kaspersky готовятся релизить Kaspersky Vulnerability Management 1.0 - первую коммерческую версию VM-решения, анонсированного в сентябре прошлого года

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

Коллеги из Kaspersky готовятся релизить Kaspersky Vulnerability Management 1.0 - первую коммерческую версию VM-решения, анонсированного в сентябре прошлого годаКоллеги из Kaspersky готовятся релизить Kaspersky Vulnerability Management 1.0 - первую коммерческую версию VM-решения, анонсированного в сентябре прошлого годаКоллеги из Kaspersky готовятся релизить Kaspersky Vulnerability Management 1.0 - первую коммерческую версию VM-решения, анонсированного в сентябре прошлого годаКоллеги из Kaspersky готовятся релизить Kaspersky Vulnerability Management 1.0 - первую коммерческую версию VM-решения, анонсированного в сентябре прошлого года

Коллеги из Kaspersky готовятся релизить Kaspersky Vulnerability Management 1.0 - первую коммерческую версию VM-решения, анонсированного в сентябре прошлого года. 16 июля они проведут вебинар, на котором обещают показать:

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

Также на сайте выложили довольно прикольный рекламный ролик. Что-то в стиле фильма Трон. Стильненько, красиво. 👍 Закадровый текст:

"Каждая IT-инфраструктура скрывает риски: уязвимости, ошибки конфигурации, устаревшее ПО. Но найти их недостаточно. Важно понять, что действительно угрожает бизнесу и устранить это вовремя. Наше решение объединяет функционал обнаружения, приоритизации и контроля устранения уязвимостей в единый процесс. Обнаруживайте и устраняйте слабые места в инфраструктуре, пока они не превратились в инциденты. Решение для управления уязвимостями - Kaspersky Vulnerability Management."

К релизу они сделали новый лендинг и буклет в pdf.

Kaspersky Vulnerability Management позиционируется как новое решение «Лаборатории Касперского» корпоративного уровня для централизованного управления уязвимостями и мисконфигурациями. Решение помогает выявлять и устранять уязвимости в IT-инфраструктурах, приоритизировать их с учетом реальных рисков и автоматизировать процессы исправления.

В буклете заявляется, что

1️⃣ Система помогает выявлять и устранять уязвимости в IT/OT инфраструктурах, приоритизировать их с учетом реальных рисков и автоматизировать процессы устранения.

2️⃣ Kaspersky Vulnerability Management станет частью Open Single Management Platform - единого центра управления решениями Лаборатории Касперского в области EPP, EDR, XDR и SIEM.

3️⃣ Платформа позволит быстро строить карту сети для управления активами, легко интегрироваться с решениями Лаборатории Касперского для индустриальной безопасности, Threat Intelligence и другими продуктами, а также обеспечит богатый набор отчетов и виджетов.

4️⃣ AI-функциональность решения дополнит мультиагентная GenAI‑система Сбера для автоматизации проверки защищенности инфраструктуры. Проект реализуется в рамках технологического партнерства «Лаборатории Касперского» и Сбера, направленного на создание AI-решений для повышения уровня кибербезопасности бизнеса.

На лендинге и в буклете заявляется следующая функциональность:

🔸 Инвентаризация и управление активами. Автоматическое обнаружение устройств, операционных систем и установленного ПО (Windows, Linux). В буклете ещё добавляют "Формирование карты сети для последующего анализа" с припиской "Будет доступно в 2027 году — сроки выхода функционала могут корректироваться компанией".

🔸 Агентное и безагентное сканирование. Для агентного сканирования используются существующие агенты Kaspersky Endpoint Security. Безагентное сканирование формулируют так "сетевое сканирование портов и сервисов". В буклете формулируют более явно "Безагентное сетевое blackbox-сканирование портов и сервисов и поиска уязвимостей". Сканирования с аутентификацией пока нет.

🔸 Проверка конфигураций. Оценка соответствия стандартам безопасности и регуляторным требованиям. Поддержка готовых профилей ФСТЭК №17, №21, №31, №239.

🔸 Патч-менеджмент. Управление обновлениями Windows через интеграцию с Kaspersky Security Center Linux.

В буклете добавляют по будущей функциональности:

"В будущих версиях продукта решение получит расширенный набор возможностей: поддержку методологии ФСТЭК для приоритизации уязвимостей, whitebox-сканирование сети, интеграцию с Kaspersky SIEM и REST API для внешних систем и другой функционал по контролю уязвимостями и мисконфигурациями."

На лендинге и в буклете приводятся несколько различающиеся схемы архитектуры решения. Наиболее интересная подробность там то, что интерфейс решения реализован в рамках веб-консоли Kaspersky Security Center.

Основное конкурентное преимущество, на котором делают акцент маркетологи Kaspersky - использование для сканирования уже развёрнутых агентов KES (Network Agent 16.3 и выше).

Руководители национальных агентств кибербезопасности альянса Five Eyes (США, Великобритания, Канада, Австралия и Новая Зеландия) призвали ускорить устранение уязвимостей, отказаться от легаси-систем и навести порядок на периметре

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

Руководители национальных агентств кибербезопасности альянса Five Eyes (США, Великобритания, Канада, Австралия и Новая Зеландия) призвали ускорить устранение уязвимостей, отказаться от легаси-систем и навести порядок на периметре

Руководители национальных агентств кибербезопасности альянса Five Eyes (США, Великобритания, Канада, Австралия и Новая Зеландия) призвали ускорить устранение уязвимостей, отказаться от легаси-систем и навести порядок на периметре. AI радикально ускоряет и усложняет киберугрозы: атаки становятся быстрее, масштабнее и доступнее для злоумышленников, а время между обнаружением уязвимости и её эксплуатацией сокращается всё сильнее. Frontier AI (самые передовые и мощные модели искусственного интеллекта, находящиеся на границе текущих возможностей ИИ и задающие новый уровень развития) уже сейчас меняет баланс сил в киберпространстве, одновременно усиливая как возможности атакующих, так и обороняющихся. При этом киберриски перестают быть чисто технической проблемой и становятся критическим бизнес-риском, требующим внимания руководства и советов директоров.

Организации должны усиливать базовые практики кибербезопасности, повышать устойчивость ("resilience") и активно внедрять AI в защиту - для раннего выявления уязвимостей, анализа аномалий и ускорения реагирования на инциденты. Успех зависит не от количества инструментов, а от качества базовой кибердисциплины, скорости реакции и интеграции безопасности в стратегию бизнеса. Те, кто НЕ адаптируется быстро, столкнутся с растущими операционными и стратегическими рисками.

Ключевые действия для руководителей

Основные принципы:

🔻 Подход secure-by-design и secure-by-default должен стать стандартной практикой, а не просто декларируемым стремлением ("aspiration").
🔻 Устойчивость не может зависеть от одного решения или технологии. Многоуровневая защита ("defence in depth") остаётся необходимой.
🔻 По мере развития AI-систем будут появляться новые и ранее неизвестные уязвимости, включая zero-day уязвимости.
🔻 Инциденты ("breaches") будут происходить. Подготовка помогает быстро их локализовать и не допустить перерастания в серьёзные операционные и финансовые кризисы.

Практические действия

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

🔸 Сократите поверхность атаки: ограничьте ненужный доступ к системам и внешние подключения. Оценивайте, действительно ли системы должны быть доступны извне, и изолируйте те, которым это не требуется.
🔸 Ускорьте процессы установки патчей: AI сокращает время между обнаружением уязвимости и её эксплуатацией. Задержки с обновлениями увеличивают риск, особенно для производственных ("operational") систем с длинными циклами обновления. Приоритизируйте обновления безопасности соответственно.
🔸 Решайте проблему устаревших систем: неподдерживаемые системы - лёгкие цели. Это не просто технический долг, а стратегические обязательства ("liabilities").
🔸 Пересмотрите и усилите контроль идентификации и доступа: ограничьте, кто может получать доступ к критическим системам. Внедряйте строгую аутентификацию и регулярно пересматривайте права доступа.
🔸 Подготовьтесь к инцидентам заранее: тестируйте планы реагирования, обучайте команды и исходите из того, что взломы неизбежны. Фокус - на быстром сдерживании ("containment") и восстановлении.

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

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ

2 комментария

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ

Продолжая комментарии к статье Ведомостей про роль ИИ в поиске новых уязвимостей, следует отметить следующее: не так страшно детектирование zero-day уязвимостей с помощью ИИ, сколько вепонизация n-day (или уже скорее n-hour 😉) уязвимостей с помощью ИИ. Т.е. использование ИИ для разработки эксплоитов на основе патчей и публичной информации об уязвимостях. Новую неизвестную уязвимость нужно ещё понять, где искать. А найдя, придумать вменяемый сценарий атаки с эксплуатацией этой уязвимости. Это работа на удачу, своего рода золотоискательство или, вспоминая Маяковского: "…та же добыча радия. В грамм добыча, в годы труды. Изводишь единого слова [уязвимости] ради тысячи тонн словесной руды [проверенного кода и неподтвердившихся гипотез эксплуатации]." Конечно, в случае использования ПО с открытым кодом задача анализа упрощается. Но всё равно найти что-то стоящее весьма непросто. Поэтому, кстати, я противник того, чтобы результаты этой добычи бесконтрольно утекали за рубеж.

Другое дело, когда уязвимость уже известная, с присвоенным CVE, вендорским описанием, признанной критичностью и выпущенным патчем. Тут задача серьёзно упрощается.

🔹 Понятно, где искать. Очевидно, там, где вендор исправляет что-то патчем.

🔹 Понятно, что нужно получить в результате. То, о чём вендор сообщил в описании уязвимости.

Задача разобраться, как именно эксплуатировать уязвимость и разработать утилиту для этого тоже непростая, но всё же гораздо проще, чем искать что-то совершенно новое. Этим можно заниматься на потоке. Например, маркетинг компании watchTowr Labs практически полностью построен на том, что они быстро анализируют патчи для устранения уязвимостей сетевых устройств и публикуют по ним публичные исследования и эксплоиты.

Естественно, этим занимаются не только исследователи watchTowr Labs. 😏 Тем более, что ИИ-агенты значительно упрощают процесс вепонизации, а то и полностью его автоматизируют. Как сообщает Денис Макрушин, стоимость автономной разработки эксплоита сейчас может составлять даже меньше 3 долларов. И ведь прогресс в ИИ пока не останавливается! Разработанные эксплойты могут выкладываться исследователями в паблик ради самопиара и общественного блага (ну, как они его себе видят), а могут и не выкладываться, а, например, продаваться на чёрном рынке. 😈 А затем эти эксплоиты будут использоваться в атаках на организации, пока их не спалят и факт эксплуатации уязвимости не станет подтверждённым. И всё это бесконечно повторяется для всё новых и новых уязвимостей. It's the circle of life and it moves us all…

Что вся эта движуха означает для простого VM'щика? Нарратив, который двигали многие VM-вендоры: "Патчьте только 3% уязвимостей, которые мы вам подсветим, а на остальные просто забейте", с самого начала выглядел булшитненько и безответственно, а в условиях ускорения и удешевления вепонизации n-day-уязвимостей и подавно. Аргументов, что любая уязвимость может внезапно выстрелить и привести к инциденту, значительно прибавилось. А значит, нужно стремиться к приоритизированному устранению всех уязвимостей, что создаёт значительную нагрузку на IT, особенно если IT-инфраструктура организации не была изначально рассчитана на непрерывную установку и тестирование обновлений безопасности. 🤷‍♂️ То, что VM-щик сможет запросто влиять на изменение инфраструктуры организации - сценарий более чем оптимистичный, на который не стоит всерьёз рассчитывать. Но агитировать за такие архитектурные изменения и стараться заводить задачи на устранение всех выявленных уязвимостей - святая обязанность VM-щика. Делай, что должен, и будь, что будет.

Инфосистемы Джет выложили "Результаты тестирования решений для управления уязвимостями" по новой версии методики (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-шек, чтобы была видна разница в реализованной логике детектирования. Возможно, когда-нибудь и это сделают. 🙂

Вышел эпизод "Почему компании не закрывают уязвимости?" [Belyaev_Podcast] с моим участием

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

Вышел эпизод "Почему компании не закрывают уязвимости?" [Belyaev_Podcast] с моим участием. Вместе с Дмитрием Беляевым и Рустамом Гусейновым обсудили Vulnerability Management и Exposure Management, CVSS/EPSS/KEV и приоритизацию уязвимостей, AI-агентов и нейросети в триаже, автоматизированный патчинг, моделирование атак, зашивание безопасности в разработку, проблемы взаимодействия с IT, работу с системами, которые нельзя патчить, будущее VM-специалистов и особенности управления уязвимостями в Linux, Kubernetes, контейнерах и облаках. Классно посидели, мне очень понравилось. Надо будет как-нибудь продолжить общение по теме. 😉

Таймстемпы:

00:00 Приветствие, медиа-партнёры
03:25 Справедливо ли мнение, что CVSS как основная метрика приоритизации - это уже "технология 2002 года"? Почему в 2026 году компании всё ещё живут в логике "сортируем по CVSS", хотя есть EPSS, KEV и трендовые метрики? Это лень, незнание или инерция?
07:49 Насколько вопросы триажа, ранжирования и приоритизации уязвимостей делаются лучше с помощью нейросетей? Будет ли в будущем происходить быстрое сопоставление по разным шкалам и интегральная оценка с учётом искажений, которые есть в тех или иных системах метрик?
10:09 Автономные AI-агенты и VM
12:00 System-hardening и патчинг уязвимостей агентами без участия человека - уже реальность?
15:33 Насколько справедливо утверждение, что Exposure Management - это не просто "VM 2.0", а действительно другой взгляд на управление риском? В твоём понимании это эволюция или всё-таки революция, но с новым ценником? (Я тут попутал "croûton" и "croissant" в известной кино-цитате - сорян 🤦‍♂️🤷‍♂️🙂)
20:32 Про зашивание безопасности в IT/разработку, почему так много Linux-уязвимостей, и нужна ли замена Linux Kernel
30:08 Если завтра появится "идеальный ИИ", который с точностью 99% предсказывает, что уязвимость будет эксплуатирована в течение 30 дней, - правда ли, что роль VM-специалиста всё равно не исчезнет? В чём тогда останется человеческая зона ответственности?
32:31 О реализуемости полного моделирования путей атаки и автоматизированном реагировании
37:46 Насколько справедливо утверждение, что IT-отделы часто фактически саботируют VM? Как это выглядит на практике: это злой умысел, защита своих интересов или просто боль от перегрузки?
42:43 Как выглядит VM-процесс для систем, которые нельзя патчить или даже активно сканировать?
45:51 Как превратить IT-шников в ответственных хозяев своих активов?
48:48 Насколько сильно отличается подход к детектированию и управлению уязвимостями в Linux, контейнерах, Kubernetes и облаках от классического сканирования Windows-хостов? Где сегодня самые большие слепые зоны?
51:30 Детектирование - это только начало, а вся драма начинается после? Какие этапы после детекции чаще всего "рассыпаются" в реальных компаниях?
54:26 Блиц-вопросы
56:11 Заключение

📺 Смотрите на платформах: VK Видео, RUTUBE, YouTube.
🎧 Слушайте на платформах: Яндекс Музыка, Звук, Spotify, Pocket Casts, Deezer, Podcast Addict, Mave.

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

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

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

Что если стоимость страхования киберрисков для компании определялась бы не по анкетам, а по реальному состоянию защищённости инфраструктуры? В блоге 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 вендоры могут делать то же самое, ведь у них тоже есть данные о состоянии безопасности, на основе которых можно строить риск-отчёты для страховых. Но ключевой вопрос не в наличии данных, а в доверии и стандартизации: страховые должны признавать эти метрики объективными и использовать их в андеррайтинге.