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

VM-ный миф № 1: качество детектирования уязвимостей у всех САЗ (Средств Анализа Защищённости) одинаковое

VM-ный миф № 1: качество детектирования уязвимостей у всех САЗ (Средств Анализа Защищённости) одинаковое. Хочу сделать мини-серию постов о популярных заблуждениях относительно Vulnerability Management-решений и процессов. И начну с самого вредного, на мой взгляд. Что детектирование уязвимостей - это что-то не особенно сложное, и практически любой IT/ИБ-вендор может вкатиться в область VM и быстро выпустить решения с тем же качеством детектирования уязвимостей, что и у лидеров рынка.

По моему мнению, это обусловлено самой природой средств детектирования (в широком смысле). Такое средство получает доступ к некоторым активам для анализа, делает НЕЧТО, в результате чего клиент получает отчёт с обнаруженными проблемами. Как именно это НЕЧТО реализуется, по большому счёту остаётся за кадром. Это может быть какая-то примитивная логика, дающая результаты со множеством false positive и false negative-ошибок. А может быть чрезвычайно сложная логика, на реализацию, тестирование и поддержание которой тратятся внушительные ресурсы вендора.

Приведу аналогию из области медицины. Чтобы выявлять аномалии в лёгких человека, можно прослушивать их примитивной полой трубкой ("дышите - не дышите"). Можно прослушивать их, используя более продвинутый стетоскоп. 🩺 Но для более-менее серьёзных исследований требуются установки для рентгенографии, компьютерной томографии (КТ) или магнитно-резонансной томографии (МРТ).

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

В медицине ни у кого не набирается наглости выдавать обычный стетоскоп за современный аппарат МРТ или КТ.

К сожалению, в кибербезопасности - области гораздо более новой, чем медицина, и гораздо менее регулируемой, попытки выдать наспех слепленную суррогатную поделку за зрелое решение - вполне обычное дело. Так на рынке появляются VM-продукты с очень примитивной функциональностью детектирования, которые превращают процесс управления уязвимостями в профанацию. 🤦‍♂️

Хочется надеяться, что постепенная стандартизация процесса детектирования уязвимостей, а также развитие программ (обязательной?) сертификации средств анализа защищённости с проверкой их функциональных возможностей, сделают продажу таких "котов в мешке" невозможной. 🙏 Но пока, к сожалению, оценка качества детектирования остаётся делом самих клиентов.

О правильном понимании термина "exposure" ("экспозиция") в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз)

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

О правильном понимании термина "exposure" ("экспозиция") в контексте Exposure Management (Управление Экспозициями) и Continuous Threat Exposure Management (CTEM, Непрерывное Управление Экспозициями с учётом Угроз). Я решил вернуться к этому вопросу, более-менее подробно описать историю использования термина "exposure", а также обосновать, почему я считаю корректным определять термин "exposure" как "уязвимость в широком смысле". Сделаю я это на основе своих выступлений и дискуссий на конференциях Security Summit, Территория Безопасности и Периметр, а также семинаре компании "Киберпротект", проходивших этой весной.

Повторюсь, что у меня к термину "exposure" отношение непростое. Был период, когда он мне категорически не нравился, и я выступал против его использования. Но постепенно, как в знаменитой книге Дейла Карнеги, я перестал беспокоиться и научился с ним жить. 🙂

🎓 (НЕ)Использование в академической ИБ

Когда мы говорим об уязвимостях ("vulnerability"), мы обычно понимаем под этим ошибки программного обеспечения, "баги", которые злоумышленники могут использовать для реализации своих зловредных целей. Всё у чего есть CVE или БДУ идентификатор - это уязвимость. При этом если посмотреть формальное определение уязвимости, то оно окажется гораздо более широким. У ФСТЭК это "слабость актива или управления, эксплуатация которой приведёт к реализации одной или нескольких угроз" (ISO/IEC 27000:2014) или "Недостаток (слабость) программного (программно-технического) средства или информационной системы в целом, который (которая) может быть использована для реализации угроз безопасности информации" (ГОСТ Р 56545-2015). В глосарии NIST самое популярное определение уязвимости, используемое в 17 документах, звучит так: "слабость в информационной системе, процедурах обеспечения безопасности системы, внутренних контролях или реализации, которая может быть эксплуатирована или задействована источником угрозы".

А откуда взялось "exposure"? Это слово очень многозначное как в самом английском языке, так и при переводе на русский. В зависимости от контекста его могут переводить как подвергание, выставление, выставка, местоположение, обнажение, вид и т.д.

В академической информационной безопасности термин "exposure" практически не используется. Если термин "vulnerability", согласно глоссарию NIST встречается в 39 документах, то термин "exposure" только в двух:

🔹 В документе NIST SP 800-161r1-upd1 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations под "exposure" понимается "степень, в которой организация и/или заинтересованная сторона подвержена риску".

🔹 В документе NISTIR 8286 Integrating Cybersecurity and Enterprise Risk Management (ERM) под "exposure" понимается "комбинация уровней вероятности и воздействия для риска".

Несмотря на низкую академическую востребованность, термин "exposure" в настоящее время активно используется индустриальной ИБ-экосистемой (Gartner, крупные вендоры, консалтинговые и платформенные игроки), но в иных смыслах.

⚙️ Эпоха Tenable

Одним из главных популяризаторов термина стала компания Tenable, которая с 2017 года начала продвигать концепт "Cyber Exposure" как "новую развивающуюся дисциплину управления и измерения современной поверхности атаки, позволяющую точно понимать и снижать киберриски" (Tenable Delivers Record Results in Q2 and the First Half of 2017). Однако при описании этого "Cyber Exposure" они используют термин "exposure", не определяя его. 🤷‍♂️ "Cyber Exposure также обеспечивает непрерывную видимость того, где активы защищены, а где они находятся в состоянии exposure и в какой степени, а также приоритизирует устранение проблем на основе критичности актива для бизнеса и степени выраженности exposure". Себя Tenable начали называть "Cyber Exposure company".

Также в 2017 году Tenable представили Cyber Exposure ecosystem - интеграционную экосистему, объединяющую инструменты безопасности и IT (ServiceNow, AWS, Splunk и другие) для сквозного управления киберриском за счёт обмена данными, автоматического обнаружения активов и ускорения приоритизации и устранения уязвимостей на всей современной поверхности атаки.

К 2019 году у Tenable "Cyber Exposure" уже используется как измеряемая модель киберриска: в Tenable Lumin они вводят Cyber Exposure Score, который объединяет вероятность эксплуатации уязвимостей и критичность активов, позволяет количественно оценивать уровень "exposure", сравнивать его во времени и между организациями и использовать это для приоритизации устранения рисков и принятия риск-ориентированных решений.

Таким образом, можно сказать, что до начала 2020-х годов термин "exposure" в рамках материалов Tenable не имел единого фиксированного самостоятельного определения и использовался как "плавающий" термин-оболочка, которому в разных контекстах придавались различные значения: от обозначения новой дисциплины управления и измерения киберриска, до общей подверженности риску, состояния уязвимости активов, степени их "открытости" атаке, агрегированного риска (с учётом вероятности и ущерба), интеграции уязвимостей и конфигураций в единую модель, а также количественного скоринга для ранжирования и приоритизации устранения проблем. 🤯

Читать далее →

Каналу @avleonovrus "Управление Уязвимостями и прочее" сегодня исполнилось 4 года

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

Каналу @avleonovrus "Управление Уязвимостями и прочее" сегодня исполнилось 4 года. Я календарь переверну и снова 3 июля. 🙂 Как 3 июля 2022 года я написал первый пост про необходимость скорейшей девестернизации российского IT, так и продолжаю, помимо основной темы про уязвимости и их детектирование, гнуть свою линию. За здоровый IT-лоялизм, за признание явных успехов, за поддержку наших в беде, за повышение наступательного киберпотенциала страны. Позиция эта довольно непопулярная. Особенно в недозаблокированной соевой ТэГэшечке, где в почёте бессовестный популизм и оголтелое критиканство, направленное против любых государственных инициатив. 🫠🤷‍♂️

Однако для меня очередной год писательства прошёл весьма успешно. Посты выпускал более-менее регулярно. Количество подписчиков ТГ-канала перевалило за психологически/юридически значимую отметку в 10к и достигло уже 11 600+. ТГ-канал получил почётный статус A+ и я зарегистрировал канал @avleonovrus в национальном мессенджере MAX. Там уже больше 500 подписчиков! 🔥 Просмотры/посещения на сайте avleonov.ru также выросли за год в 3-4 раза. Спасибо большое всем тем, кто подписан, читает, лайкает, комментирует и делится постами! 🙏

Я собираюсь и дальше проживать свою лучшую жизнь и с удовольствием делиться с вами своими мыслями про Управление Уязвимостями и прочее. 😇 В первую очередь планирую писать о том, что непосредственно связано с моей работой и моими около-VMными проектами (обзоры Microsoft Patch Tuesday, Linux Patch Wednesday, трендовых уязвимостей, VM-ных продуктов и изменений регуляторики), во вторую - о том, что происходит в мире Vulnerability Management-а и кажется мне по каким-то причинам важным или любопытным, а в третью - обо всём остальном, о чём посчитаю нужным: от ситуации со смартфончиками до семейного отдыха и ХудЛита. Потому что могу! 😉

А вот всерьёз заниматься развитием своего "личного бренда", стремиться к безудержному росту количества подписчиков любыми средствами, превращаться в желтушное недо-СМИ, транслирующее 24/7 нейрослопные пересказы новостей с претенциозной популистской подачей, я как-то не планирую. 😅🤷‍♂️

Погнали в следующий год!

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

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

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

Другое дело, когда уязвимость уже известная, с присвоенным 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-щика. Делай, что должен, и будь, что будет.

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире

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

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире. Сама статья за paywall-ом, и мои комментарии там, вполне естественно и ожидаемо, были сильно сокращены, поэтому я приведу их здесь в развёрнутом виде.

Насколько адекватно делать выводы о динамике раскрытия уязвимостей, основываясь только на БДУ ФСТЭК России? (такую статистику привели коллеги из ЛК, привязав к ней анонс Kaspersky VM 😉)

Говоря о базе уязвимостей БДУ ФСТЭК России, важно учитывать, что она методологически не предназначена для учёта всех существующих уязвимостей: в неё включаются данные об уязвимостях отечественных продуктов, а также иностранных коммерческих и опенсорсных решений, применяемых в ГИС и на объектах КИИ. Поэтому БДУ не покрывает весь спектр уязвимостей, актуальных для российских инфраструктур, и её данных недостаточно для анализа глобальных трендов; для этого лучше использовать более полные источники, такие как PT DBugs или NIST NVD. Для визуализации статистики NVD удобно использовать дашборды, такие как CVE ICU. Текущие данные NVD показывают значительное увеличение скорости добавления новых CVE: за одинаковый период в 2025 году было зарегистрировано 22 041 уязвимость, а в 2026 году уже 31 917, что соответствует увеличению на 44,8%.

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

Что сейчас происходит с Vulnerability Management рынком?

Рынок Vulnerability Management в последние годы растёт как в России, так и в мире. В России важным фактором стал уход западных вендоров в 2022 году, что привело к появлению новых отечественных игроков. Внутренняя конкуренция стимулирует развитие функциональности решений, повышение качества детектирования, точности приоритизации и расширение интеграций с другими средствами защиты и ИТ-системами. Отдельно стоит отметить внимание ФСТЭК России к этой теме: разработка методических документов и требований способствует формированию более структурированного подхода к управлению уязвимостями.

Если смотреть ретроспективно, рынок Vulnerability Management прошёл путь от массового сканирования и детектирования CVE-уязвимостей к платформенному управлению защищённостью инфраструктуры. Полный и качественный поиск уязвимостей остаётся важной базовой функциональностью, однако сегодня всё больше учитывается контекст: критичность затронутых активов и возможность реальной компрометации через комбинацию выявленных уязвимостей. На Западе всё чаще говорят не о классическом Vulnerability Management, а о более широком подходе - Exposure Management или Continuous Threat Exposure Management (CTEM), где объектом управления становятся не только уязвимости с CVE/BDU-идентификаторами, но и уязвимости в широком смысле ("экспозиции"): ошибки конфигурации, проблемы с учётками, небезопасные настройки, избыточная сетевая связность активов и т.п. Обнаруженные проблемы используются CTEM-решениями для моделирования возможных путей развития атаки (attack paths), что позволяет выявлять и приводить в порядок наиболее проблемные участки инфраструктуры, повышая сложность и стоимость реальной атаки для злоумышленников.

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

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

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

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

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

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

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

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

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