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

MaxPatrol Carbon - средство эффективной приоритизации уязвимостей

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

MaxPatrol Carbon - средство эффективной приоритизации уязвимостей

MaxPatrol Carbon - средство эффективной приоритизации уязвимостей. Продолжу предыдущий пост примером конкретного решения. 😉

➡️ На вход Carbon берёт данные по уязвимостям (в расширенном смысле, "экспозиции": CVE/BDU, мисконфиги, подобранные учётки и т.п.) и сетевой связности из MaxPatrol VM. ❗️Отсюда важность полноты VM-сканирования❗️ Пользователь также задаёт точки проникновения, и целевые системы.

⬅️ На выходе Carbon даёт набор потенциальных путей атаки (тысячи их!), завязанных на эксплуатацию обнаруженных уязвимостей ("экспозиций"). Причём это не условные маршруты на основе сетевой достижимости. Нет! Там полноценные сценарии с эксплуатацией RCE-уязвимостей, захватом учёток, повышением привилегий, учётом возможности подключения по легитимному протоколу и прочим. 👨‍🔬

⚖️ Пути атаки оцениваются с учётом сложности эксплуатации, длительности и количества шагов…

И только здесь начинается полноценная приоритизация уязвимостей… 😉

Книга "Эффектная приоритизация уязвимостей" от издательства O'FAILY

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

Книга Эффектная приоритизация уязвимостей от издательства O'FAILY

Книга "Эффектная приоритизация уязвимостей" от издательства O'FAILY. 🙂 На фоне громкого релиза провокационной книги от Ever Secure (кстати, 20-го июня у них автограф-сессия в Музее Криптографии), мне подумалось: а как бы могла выглядеть аналогичная книга "с тёмной стороны" на тему VM-а? Чтобы в ней были подчёркнуто вредные советы и при этом было guilty pleasure в том, чтобы её полистать. 😎😈

В итоге сформировалась идея руководства для VM-щика, который хочет стать откровенным и успешным козлом 🐐:

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

Ну, с другой стороны, книга могла бы научить, как такое поведение выявлять и пресекать. 😉

Если об эксплуатации уязвимости никто не пишет в паблике, это ещё не значит, что об эксплуатации никому не известно

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

Если об эксплуатации уязвимости никто не пишет в паблике, это ещё не значит, что об эксплуатации никому не известно

Если об эксплуатации уязвимости никто не пишет в паблике, это ещё не значит, что об эксплуатации никому не известно. Исследователи могут и молчать. 😉 В продолжение темы про недоисследованные уязвимости хочется обратить внимание на последний кейс с XSS уязвимостями в MDaemon и Zimbra. Эти уязвимости были устранены в ноябре и феврале 2024 года. У них были "средний" CVSS: 5.3 и 6.1. Тип уязвимости XSS также не является супер-критичным. Не было никаких причин приоритизировать исправление этих уязвимостей.

ПРИ ЭТОМ исследователи ESET ещё в 2024 году знали, что эти уязвимости эксплуатируются в атаках. Они сами наблюдали эту эксплуатацию. И они просто МОЛЧАЛИ до 15 мая 2025 года. Как минимум 5,5 месяцев они не выдавали информацию, которая могла бы повысить приоритет устранения этих уязвимостей и защитить пользователей от атак. Ни вендорам не сообщали, ни в CISA KEV. 🤷‍♂️

Так что не ждите сообщений об атаках - обновляйтесь при первой возможности!

Про недоисследованные уязвимости

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

Про недоисследованные уязвимости

Про недоисследованные уязвимости. Перед завтрашним выступлением на PHDays на тему приоритизации уязвимостей напомню, почему устранять следует ВСЕ уязвимости, а не только "критичные".

🔹 Для небольшого количества уязвимостей мы точно знаем, что они критически опасны: есть подробное техническое описание, проверенные публичные эксплоиты, подтверждённые случаи эксплуатации. Их меньше 1% от всех уязвимостей.

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

🔹 Остальные ~98-99% уязвимостей "недоисследованные" и наши знания о них неполны. 🤷‍♂️ Это как зловещий хтонический туман из повести Кинга. Оттуда периодически высовываются щупальца и кого-то утаскивают. 😱🐙👾 Т.е. появляются сведения об атаках с использованием уязвимости и она переходит в категорию критичных. 😏

Бойтесь недоисследованных уязвимостей и устраняйте их! 😉

Выписал тезисы по статье Алексея Лукацкого про методы приоритизации уязвимостей

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

Выписал тезисы по статье Алексея Лукацкого про методы приоритизации уязвимостей

Выписал тезисы по статье Алексея Лукацкого про методы приоритизации уязвимостей.

🔹 Количество CVE уязвимостей растёт с большим ускорением; считается, что на одну зарегистрированную уязвимость есть 3 незарегистрированных.
🔹 Исходя из статистики, устранение уязвимостей осуществляется гораздо позже, чем эти уязвимости начинают использовать атакующие.
🔹 Отсутствие выстроенного процесса приоритизации уязвимостей - одна из причин задержек в их устранении.
🔹 Единственного правильного метода приоритизации уязвимостей нет: у каждого свои преимущества, недостатки и область применения.
🔹 Выбор у корпоративных пользователей небогат: довериться методам приоритизации VM-вендора, либо пилить свой процесс (собирая temporal и environmental данные самостоятельно).
🔹 Можно попробовать разработать собственную методику, однако всё равно нужно где-то брать исходные данные. Большинство компаний берут за основу CVSS Base Score + временные метрики (EPSS, Coalition ESS, AI Score, CVE Shield, CISA KEV и т.п.). Каверзные вопросы. Что делать с новыми уязвимостями, по которым еще нет данных? И что делать с уязвимостями, для которых нет, и возможно, не будет данных в CVE (например, с уязвимостями в российских продуктах)? 🤔 Информации по их эксплуатабельности в западных источниках не будет. 😏
🔹 "Уникальная и революционная система приоритизации уязвимостей" = учёт информации о наличии эксплойта, использовании уязвимости в реальных атаках, активности обсуждения в СМИ и соцсетях и т.д. + обработка ML-ем.
🔹 Упрощённые критерии принятия решений (НКЦКИ, SSPP, CISA) всё равно требуют автоматизации и источника информации об активности эксплуатации уязвимостей вживую.

На прошлой неделе на сайте РезБеза вышел большой обзор методов приоритизации уязвимостей от Алексея Лукацкого

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

На прошлой неделе на сайте РезБеза вышел большой обзор методов приоритизации уязвимостей от Алексея Лукацкого

На прошлой неделе на сайте РезБеза вышел большой обзор методов приоритизации уязвимостей от Алексея Лукацкого. Нашлось там место и для предложенной мной альтернативы CVSS под названием ОСОКА ("Общая Система Оценки Критичности Автоматизируемая"), а также там упоминается моя утилита для приоритизации уязвимостей Vulristics. Видимо действительно пора доводить ОСОКу от разрозненных заметок до спецификации, делать калькулятор и интегрировать её в Vulristics. 🤔

Рассматриваемые в статье методы разбиты на 3 группы:

🔹Зарубежные: CVSS, EPSS, CISA SSVC, CISA KEV, CVEShield (CVE Crowd, CVETrends), CMU SSVC, CVE Prioritizer, Vulners AI Score, Zoom VISS, SSPP

🔹 Российские: методика ФСТЭК, алгоритм НКЦКИ, трендовые уязвимости Positive Technologies, ОСОКА

🔹Проприетарные / закрытые: Coalition ESS, Tenable VPR, Qualys TruRisk, MVSF, PRIOn. Здесь же упоминаются внедряемые технологии приоритизации (VPT): Vulnera VSCORE, Outpost24 VPT, Vulcan, Ridge RidgeBot

Тоже сделал мемчик с крутым Юсуфом Дикечем

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

Тоже сделал мемчик с крутым Юсуфом Дикечем

Тоже сделал мемчик с крутым Юсуфом Дикечем. 😅

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

Это суровая база. А когда вам говорят, что этого можно не делать, потому что есть какой-то супер-современный инструмент оценки уязвимостей, к этому стоит относиться со скепсисом. 😉