Посмотрел выпуск Application Security Weekly с Emily Fox про Vulnerability Management. Как это сейчас модно, ведущие и гостья накидывали в ту сторону, что известных уязвимостей сейчас слишком много, реально эксплуатируются из них 3-4%, а поэтому исправлять нужно не все уязвимости. А чтобы понимать, что именно не нужно исправлять, требуется

🔹 Учитывать слои безопасности препятствующие эксплуатации уязвимости.
🔹 Учитывать зависимость риска эксплуатации от типа уязвимого актива.
🔹 Оценивать вероятность эксплуатации в контексте конкретной организации.

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

Чтобы можно было бы дать руку на отсечение, что вот эту уязвимость исправлять 100% не нужно и эта уязвимость никогда не будет активно эксплуатироваться в атаках. 🙋‍♂️ И проделывать это не для одной уязвимости, а массово. Есть такие смельчаки с лишними руками? Имхо, если ты не готов так делать, то не должен и утверждать, что какие-то уязвимости можно оставить без исправления.

Если уязвимость (даже потенциально) есть и она может быть исправлена обновлением, то она ДОЛЖНА быть исправлена обновлением. Планово или быстрее, чем планово. Но исправлять нужно всё. При этом отказ от уязвимых активов, софтов, компонентов, образов это вполне себе хороший способ исправления. Чем меньше поверхность атаки, тем лучше. Если обновляться по каким-то причинам сложно и больно, то в первую очередь нужно решать с этим вопрос. А почему это сложно и больно? Что не так с базовыми процессами организации, что мы не можем обновляться? Может в сторону более правильной архитектуры нужно посмотреть?

Это лучше, чем делать ненадежные предположения, что возможно эта уязвимость не настолько критичная, чтобы её исправлять. Потому что, как правило, об этих уязвимостях мы практически ничего не знаем: сегодня она неэксплуатабельная, а завтра станет эксплуатабельной, а послезавтра её будут эксплуатировать все скрипткидисы. Возможно, что эту уязвимость уже несколько лет как активно используют в таргетированных атаках. Кто может сказать, что это не так?

Весьма симптоматично, кстати, что в этом эфире рекомендовали использовать EPSS для выборки наиболее потенциально опасных уязвимостей. 🤦‍♂️ Инструмент, который, к моему глубокому сожалению, просто не работает и показывает низкие значения вероятности появления эксплоита для активно эксплуатирующихся уязвимостей и высокие значения для тех уязвимостей, эксплоиты для которых не появляются годами. 🤷‍♂️

Посмотрите например в моём отчёте Vulristics для Февральского Microsoft Patch Tuesday. Elevation of Privilege - Windows Kernel (CVE-2024-21338) в CISA KEV, а значения EPSS у неё низкие (EPSS Probability is 0.00079, EPSS Percentile is 0.32236). 🤡 С тем же успехом можно на кофейной гуще гадать, может даже эффективнее будет. Поэтому и остальная "магия триажа" также вызывает скепсис.

Ещё раз:

🔻 Исправлять нужно все продетектированные уязвимости в соответствии с рекомендациями вендора.
🔻 В первую очередь нужно исправлять то, что реально эксплуатируется в атаках или будет эксплуатироваться в ближайшее время (трендовые уязвимости).

Alexander Leonov

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно прочитать здесь. Приглашаю подписаться на мой канал в Telegram @avleonovrus. Я обновляю его чаще, чем этот сайт. Вы можете обсудить мои посты или задать вопросы в @avleonovchat или в группе ВКонтакте.

And I invite all English-speaking people to another telegram channel @avleonovcom.