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

Верный признак хорошего вендора средств детектирования уязвимости — это то, что его сотрудники делится экспертизой по детектированию уязвимостей на конференциях, в статьях, видео-роликах и т.д

Верный признак хорошего вендора средств детектирования уязвимости - это то, что его сотрудники делится экспертизой по детектированию уязвимостей на конференциях, в статьях, видео-роликах и т.д

Верный признак хорошего вендора средств детектирования уязвимости — это то, что его сотрудники делится экспертизой по детектированию уязвимостей на конференциях, в статьях, видео-роликах и т.д.

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

А когда этого нет, возникают вопросы:

🔹 Может детектирование уязвимостей это примитивная сфера деятельности и обсуждать там нечего? Но мы-то знаем, что сложностей там хватает. 😉

🔹 Или, возможно, для вендора качество и полнота детектирования уязвимостей не являются приоритетом? 😏 Разработчики правил детектирования что-то пилят на расслабоне. Клиентам вроде норм. В этом случае акцентировать лишнее внимание на детектах невыгодно, так ведь? 🙈🙊

В общем, техническим статьям про детект уязвимостей всегда рад, стараюсь читать и подсвечивать. 😉 Если вдруг что-то пропустил, пишите в личку — исправлюсь.

Защита на 100%?

Защита на 100%?

Защита на 100%? В канале Дениса Батранкова, если кто не знает, он известный эксперт по сетевой безопасности, вышел пост о невозможности стопроцентной защиты. Обосновывает он это как раз со стороны Управления Уязвимостями:

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

🔹 0day уязвимости начинают эксплуатироваться до появления патчей и от них VM в принципе не спасает

Полностью согласен. Я бы ещё со ссылкой на БОСПУУ, обратил внимание на то, что

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

🔸 средства детектирования уязвимостей имеют свои функциональные ограничения, которые необходимо иметь в виду

В целом, речь, конечно, не идёт ни о каком достижении 100% защиты, а об избежании стопроцентного решета, которое возникает, если Vul­ner­a­bil­i­ty Man­age­ment-ом (и информационной безопасностью вообще) не заниматься. 🤷‍♂️

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

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

А можно мне, пожалуйста, не заниматься оценкой адекватности средств детектирования уязвимостей? Не проверять достаточность детектов, а тем более их фактическую реализацию.

Да можно. 🙄 Я вообще мало знаю людей, кто этим заморачивается. К сожалению, большинство относится формально. Принимают всё на веру, VM-вендоров лишний раз не стимулируют. 🤷‍♂️

К чему это приводит? Маркетинг VM-вендоров решает, что детекты это коммодити, качество их никому не интересно и продажи не улучшает. Разработчики в VM-вендорах расслабляются. Главное же, чтобы на полностью обновлённой системе всё зелёненькое было, а на необновлённой красненькое. Остальное не так и важно, правда? 😏 VM-продукты деградируют.

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

В итоге имеем порочный круг лени и наплевательства, который гробит всю идею VM‑а. 😔

А ты точно умеешь это детектировать? В продолжение предыдущего поста про оценку адекватности средств детектирования уязвимостей

А ты точно умеешь это детектировать? В продолжение предыдущего поста про оценку адекватности средств детектирования уязвимостей

А ты точно умеешь это детектировать? В продолжение предыдущего поста про оценку адекватности средств детектирования уязвимостей. Безусловно, недостаточно одной констатации VM-вендором, что тот или иной способ детектирования уязвимостей реализован в полной мере. Нужно идти ещё глубже.

Берём тот же базовый пример: детектирование уязвимостей на Lin­ux хосте в пакетах из официального репозитория. Казалось бы — чего проще. Парсишь бюллетени безопасности (или даже готовый OVAL-контент Lin­ux-вендора берёшь) и сравниваешь версии пакетов.

В реальности ошибиться можно много где. Самое частое:

🔹 Функция сравнения версий пакетов (например, эпоху не учитывают)
🔹 Источник безопасных версий пакетов (когда в бюллетенях source пакеты, а от них нужно перейти к версиям бинарных пакетов).

Особенно наглядно бывает, когда один хост проверяется несколькими сканерами. И в случае расхождений каждый вендор говорит, что их результаты правильные. 🤷‍♂️🤪 Пока не будет доказано обратное. 😏

Оценка адекватности используемых решений по детектированию уязвимостей

Оценка адекватности используемых решений по детектированию уязвимостей

Оценка адекватности используемых решений по детектированию уязвимостей. Заканчиваю отвечать на пост Алексея Лукацкого с критикой БОСПУУ. Согласен, что оценивать полноту базы детектов уязвимостей и достаточность способов детектирования непросто, и это имеет смысл только в контексте инфраструктуры конкретной организации.

Как оценивать?

🔹 Видим актив в инфре. Задаём вопрос: он в принципе поддерживается средством детектирования?

Если нет, то чешем репу, что делать: стимулировать VM-вендора, покупать другую детектилку / делать её самим, менять инфру.

Если да, идём глубже.

🔹 А как именно происходит детектирование?

Допустим, это Lin­ux хост, и сканер детектирует уязвимости ТОЛЬКО в пакетах установленных из официального репозитория.

Нам этого достаточно? У нас там точно нет софта, установленного по-другому? 😏

Если достаточно, то всё ок.

Если нет — чешем репу как расширить способы детекта (пентест/WEB, анализ контейнеров и т.п.). Или меняем инфру. 🤷‍♂️

Далее

Где SLA, Лебовски?

Где SLA, Лебовски?

Где SLA, Лебовски? В посте с критикой БОСПУУ Алексей Лукацкий задаёт вопрос про SLA для задач на устранение уязвимостей: "Кто его устанавливает? ИТ?" И дальше предполагает, что сроки для устранения критичных уязвимостей будут неадекватно завышены.

Здесь сошлюсь на хорошую статью по управлению уязвимостями, которую я уже разбирал ранее.

SLA на выполнение задач по устранению уязвимостей (плановому и приоритетному) согласовывают совместно ИБ и ИТ/бизнес.

При этом учитывается:

🔹 критичность активов
🔹 требования к доступности активов и к версионности
🔹 технологические окна

Если какие-то активы невозможно обновлять даже в окна, следует рассмотреть возможность дублирования систем или обновления по частям.

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

БОСПУУ и светофоры

БОСПУУ и светофоры

БОСПУУ и светофоры. То, что вы видите на схеме БОСПУУ это характеристики нормального функционирующего Vul­ner­a­bil­i­ty Man­age­ment процесса. Есть адекватный поток продетектированных уязвимостей, он обрабатывается, задачи на устранение уязвимостей заводятся, выполнение задач отслеживается.

А что, если у вас, как в посте Алексея Лукацкого, 10% активов не покрыты детектами? И, более того, эти активы не оценены и вы не знаете есть ли там целевые или ключевые системы. Это значит, что нормального VM-процесса у вас нет. 🤷‍♂️ И ваши красивые дашборды не отображают реального состояния инфры. Можно, как описывается в том же посте, спрятаться за светофорчик: 90% есть, красим в зелёненький. 🚦👌 Но это самообман и обман руководства организации. Заканчивается это плохо. В случае инцидента светофорчик вас не спасёт.

Рекомендую не приукрашивать положение дел, а приводить VM-процесс к нормальному функционирующему состоянию, которое подразумевает контроль всех активов и всех уязвимостей.