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

В свежем выпуске журнала Information Security вышел традиционный спецпроект по Управлению Уязвимостями, в котором я принял участие

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

В свежем выпуске журнала Information Security вышел традиционный спецпроект по Управлению Уязвимостями, в котором я принял участие

В свежем выпуске журнала Information Security вышел традиционный спецпроект по Управлению Уязвимостями, в котором я принял участие. Всего там было опубликовано 10 материалов. Если суммировать, то в этом году эксперты в основном разбирали ограничения классического VM-подхода: рост числа CVE, недостаточность CVSS, необходимость учета реальной эксплуатабельности уязвимостей и контекста активов, переход к Exposure Management / CTEM, Realtime VM, TPRM и автоматизации приоритизации и устранения уязвимостей. Вот перечень материалов и краткие выжимки:

🔻 Виктория Шишкина, Positive Technologies. От хаоса к контролю: ошибки в управлении уязвимостями и метрики зрелости процесса. Эффективное управление уязвимостями невозможно без измеримых метрик, которые позволяют контролировать полноту инвентаризации активов, качество выявления, приоритизацию и своевременность устранения уязвимостей и ошибок конфигурации.

✳️🔻 Александр Леонов, Positive Technologies. CVE - только начало: Как Exposure Management меняет правила игры. Exposure Management расширяет классическое управление уязвимостями: вместо фокусировки только на CVE он учитывает любые факторы, повышающие риск атаки (ошибки конфигурации, избыточные права, слабые настройки и архитектурные недостатки), анализирует реальные пути атак и помогает устранять наиболее опасные экспозиции с учетом бизнес-контекста.

🔻 Security Vision. Восемь слагаемых процессов VM нового поколения. Современные платформы управления уязвимостями должны не просто находить CVE, а непрерывно оценивать реальные риски, анализировать поверхность и маршруты атак, контролировать устранение и объединять все процессы в единую систему управления безопасностью.

🔻 Мария Тимофеева, RedCheck. Проблемы источников сведений об уязвимостях в 2026 году. Из-за роста числа уязвимостей, ограничений CVSS и снижения полноты данных в NVD компании переходят к многоканальному сбору сведений, риск-ориентированной приоритизации и усилению роли экспертной аналитики и ИИ в управлении уязвимостями.

🔻 Владимир Михайлов, Vulns io. Realtime VM для противодействия эксплуатирующему ИИ. Переход от периодического сканирования к Realtime VM позволяет за счет непрерывного контроля инфраструктуры, оперативного обновления данных об уязвимостях и автоматизации устранения сократить время реакции на новые угрозы с часов до минут.

🔻 Никита Котиков, CICADA8. Иллюзия контроля: почему Excel-анкеты не защищают от атак через контрагента. Оценка рисков контрагентов должна переходить от формальных Excel-анкет к доказательному и непрерывному контролю через TPRM (Third-Party Risk Management), который анализирует реальные технические данные, выявляет скрытые риски и обеспечивает постоянный мониторинг безопасности цепочки поставок.

🔻 Александр Дорофеев, Эшелон Технологии. Внешние индикаторы реальной опасности уязвимостей. Эффективная приоритизация уязвимостей требует отказа от оценки только по CVSS и учета дополнительных индикаторов - вероятности эксплуатации EPSS, фактов атак из CISA KEV, наличия эксплойтов, критичности активов и внутреннего контекста риска.

🔻 Иван Елисеев, Check Risk. Неужели VM-системы подходят к пределу своих возможностей? VM-системы сталкиваются с ограничениями из-за роста числа CVE, ускорения появления эксплойтов и снижения эффективности приоритизации по CVSS/EPSS, поэтому рынок смещается к Exposure Management, где оценивается не сама уязвимость, а реальная вероятность атаки с учетом доступности актива, эксплуатируемости и бизнес-контекста.

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

🔻 Российские решения для управления уязвимостями. Сравнительная таблица MaxPatrol VM, Security Vision NG VM, RedCheck, Сканер-ВС, Vulns.io VM, CICADA8 VM, Kaspersky VM. Критерии сравнения включают сертификацию и наличие в реестрах, позиционирование, охват активов, возможности внешнего сканирования, источники данных об уязвимостях и активах, ИИ-анализ, приоритизацию, подтверждение эксплуатации, анализ путей атак, автоматизацию устранения, интеграции и дополнительные функции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководители национальных агентств кибербезопасности альянса 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-ная тема, в связи с бурным развитием технологий ИИ, актуальна для англосаксов как никогда. 😎 И нам тоже стоит к этим призывам прислушаться. 😉

Выступил сегодня на семинаре "Управление непрерывностью бизнес-процесса: технические аспекты" для студентов и преподавателей ВУЗов

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

Выступил сегодня на семинаре Управление непрерывностью бизнес-процесса: технические аспекты для студентов и преподавателей ВУЗов

Выступил сегодня на семинаре "Управление непрерывностью бизнес-процесса: технические аспекты" для студентов и преподавателей ВУЗов. Онлайн-трансляцию вели из Центра технологий и решений компании Киберпротект. В семинаре приняли участие студенты безопасники из СибГУ им. М.Ф. Решетнева, ИТМО, Университета Иннополис и ряда других ВУЗов.

🔹 Я рассказал о переходе от классического Vulnerability Management к концепции Continuous Threat Exposure Management (CTEM), где экспозиции рассматриваются как "уязвимости в широком смысле", а моделирование путей атаки (attack paths) позволяет выявлять и устранять наиболее полезные для злоумышленников экспозиции.

🔹 Вячеслав Золотарев, зав. кафедрой безопасности информационных технологий СибГУ им. М.Ф. Решетнева, рассказал о работе с достижимостью и эксплуатабельностью как элементе оценки устойчивости бизнес-процесса и плана его восстановления.

🔹 Михаил Толчельников, директор по ИБ Киберпротект, рассказал о киберустойчивости, управлении рисками и роли CISO (трансформации от "настройщика фаерволов" к бизнес-партнёру, снижающему неопределённость), затронул подходы к построению киберустойчивости, снижению стоимости владения ИБ и подготовке к неизбежному кризису через управление рисками на дистанции.

🔹 Владимир Маракшин, директор департамента стратегического развития Киберпротект, рассказал о различии между защитой и устойчивостью, типичных зонах сбоев, иллюзии контроля и ложном чувстве безопасности, управленческих заблуждениях, ранних сигналах ослабления инфраструктуры и решениях, которые со временем превращаются в риски.

Хорошо пообщались и подискутировали о разных аспектах управления ИБ, терминологии, роли Gartner-а в маркетинге ИБ решений и дали советы студентам. Большое спасибо компании Киберпротект за мероприятие! 🙂

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

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

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

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