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

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

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

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

При всём моём принятии любых подходов к детектированию уязвимостей, есть одна вещь, которая мне однозначно не нравится. Когда VM-вендор реализует некоторый подход к детектированию (условный Best Detection & Scanning Method 😏) и начинает применять его везде и всегда как самый лучший и правильный.

Частенько оказывается, что гибкость реализованного подхода недостаточна, чтобы получать качественные результаты детектирования уязвимостей для некоторых типов активов. Гладко было на бумаге, да забыли про овраги. 🤷‍♂️

Правильным решением такое ситуации выглядит:

🔹 Публично признать проблему, покаяться перед клиентами.
🔹 Реализовать подход, обеспечивающий наилучшее качество детектирования.

Но VM-вендоры могут вместо этого включать режим "пренебречь - вальсируем". 😐 Тоже понятно почему: доработка требует ресурсов, а клиенты фолсы могут и не заметить. 😉 Такие кейсы, имхо, следует аккуратно подсвечивать и стимулировать вендоров к повышению качества детектирования.

Важно ли, что именно у сканера уязвимостей "под капотом"?

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

Важно ли, что именно у сканера уязвимостей под капотом?

Важно ли, что именно у сканера уязвимостей "под капотом"? На презентации Сканер-ВС 7 Александр Дорофеев поднял интересную тему сравнения подходов к детектированию уязвимостей. Поделюсь своим мнением:

🔹 Я видел много разных сканеров уязвимостей, и у меня сейчас нет предпочтений в том, как должна описываться логика детектирования уязвимостей. Глядя со стороны клиента, мне без разницы, что у сканера "под капотом": NASL/NSE/NucleiTemplates, SCAP/OVAL/NVD CPE Configurations, свои форматы описания логики на основе XML и YAML, любые таблички с версиями или произвольные скрипты. 🤷‍♂️

🔹Я даже не против, если для разных типов сканирования и/или разных типов активов будут использоваться различные подходы к детектированию. Вообще пофиг - хоть на таро гадайте. 🃏😏

Определяющим для меня является только одно - итоговое качество детектирования: чтобы количество ошибок первого и второго рода в результатах было минимальным. А как этого добивается VM-вендор - его проблемы.

Вчера в офисе Positive Technologies прошли ИТ-посиделки

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

Вчера в офисе Positive Technologies прошли ИТ-посиделки

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

От практикума по Управлению Уязвимостями выступал я и Олег Кочетов. Очень приятно было услышать позитивные отзывы, как коллеги-выпускники применяют полученные знания в работе и как им это помогло в карьерном росте. 😇 Предложения по улучшению тоже зафиксировали и взяли в работу. 🙂 Кулуарно про реалии VM-ного рыночка тоже посплетничали - куда ж без этого. 😉

➡️ Следующий набор на VM-ный практикум стартует уже 9 июня, до пятницы можно успеть зарегистрироваться. Я буду участвовать в вебинарах в рамках курса и отвечать на вопросы участников. 😉

Разговоры с чудаками и Управление Уязвимостями

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

Разговоры с чудаками и Управление Уязвимостями

Разговоры с чудаками и Управление Уязвимостями. Согласен с Алексеем Лукацким, что тратить бесценное время жизни на общение с токсичными чудаками решительно не хочется. Но что делать, если это требуется в рамках рабочего процесса? Например, когда коллеги из IT или бизнеса уклоняются от устранения уязвимостей на своих активах, используя разнообразные риторические приёмы.

Имхо, главное беречь свою психику:

🔹 Стараемся не вовлекаться эмоционально. Наблюдаем за перфомансом токсичного коллеги как психиатр за пациентом. Слушаем, фиксируем, прикидываем "диагноз". На словесные выпады не ведёмся. 👨‍⚕️

🔹 Используем стандартную формальную аргументацию, отсылающую (поэтапно) к политикам организации, требованиям регуляторов и уголовному кодексу. ⚖️👮

🔹 Используем стандартную аргументацию, отсылающую к публичным инцидентам. 👾

🔹 На "докажи-покажи" не ведёмся, а вместо этого методично собираем доказательства, что работы не выполняются и поэтапно эскалируем это на руководство. ⬆️😏

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некорректная постановка задачи и нереалистичные ожидания со стороны клиентов приводят к ущербному Vulnerability Management процессу

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

Некорректная постановка задачи и нереалистичные ожидания со стороны клиентов приводят к ущербному Vulnerability Management процессу

Некорректная постановка задачи и нереалистичные ожидания со стороны клиентов приводят к ущербному Vulnerability Management процессу. Как сейчас выглядит типичное внедрение VM-процесса в организации? Клиент приходит к VM-вендору и хочет получить от него решение, которое сможет сходу детектировать 100% уязвимостей на 100% активах в его инфраструктуре со 100% достоверностью. 💊 Причём независимо от того какой треш, угар и чад кутежа творится в инфраструктуре клиента. 🤷‍♂️ Ну, не менять же инфру ради какого-то там VM-процесса, правда? 😏

И тут бы VM-вендору сказать, что нет, так не получится… Но кушать все хотят. И обычно VM-вендор делает вид, что такая постановка задачи ему вполне ок. 👌 А клиент делает вид, что у него теперь есть работающий VM-процесс, всё детектится и устраняется. 👨‍💻 Стороны держат покер-фейс, а неудобную тему качества детектирования стараются не замечать. 😐

В результате часть инфраструктуры остаётся в "слепых пятнах". И там, естественно, самое адище. 😈