Архив метки: 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-процесс к нормальному функционирующему состоянию, которое подразумевает контроль всех активов и всех уязвимостей.

Обновил схему Базовой Оценки Состояния Процесса Управления Уязвимостями (БОСПУУ)

Обновил схему Базовой Оценки Состояния Процесса Управления Уязвимостями (БОСПУУ)

Обновил схему Базовой Оценки Состояния Процесса Управления Уязвимостями (БОСПУУ). Теперь там 4 компонента:

🔻 Адекватность используемых решений по детектированию уязвимостей
🔻 Анализ уязвимостей и заведение задач на устранение уязвимостей 🆕
🔻 Охват инфраструктуры, работа с активами и ответственными за устранение уязвимостей
🔻 Отслеживание выполнения SLA по задачам на устранение уязвимостей для скоупов активов

По сравнению с версией 0.0.5, разнёс работу с активами/ответственными и анализ уязвимостей/заведение задач на исправление. Подрихтовал формулировки, чтобы было меньше неоднозначного. Сознательно убрал про сканирование сетей — это укладывается в "нет активов без регулярных проверок на уязвимости".

Это всё ещё драфт, но вроде выглядит уже более-менее прилично и кажется, что всё основное в VM-процессе охватывает. Можно потихоньку отвечать на критику от Алексея Лукацкого. 😉

Если видите недочёты — не стесняйтесь, пишите в личку @leonov_av. 🙂

В непожатом виде