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

Аксиома обновления до последней версии ПО

Аксиома обновления до последней версии ПО

Аксиома обновления до последней версии ПО. В комментариях к посту про Vulnerability Management как порождение хаоса в IT (пользуясь случаем, всех приглашаю комментировать мои посты в VK и добавляться в друзья 😉) Михаил Богаченко подсветил интересную тему. Мы действительно зачастую берём некоторые аспекты Vulnerability Management-а как аксиомы, которые не требуют доказательств.

В случае, если нужно закрыть уязвимость мы зачастую можем рекомендовать "обновиться до последней версии ПО". Хотя эта последняя версия ПО может, например, содержать бэкдор. Как было в случае с XZ Utils, 3CX Desktop App и Free Download Manager. Так что рекомендация может привести к инциденту. 🤷‍♂️ И кто будет в этом случае отвечать? 😏

Причём ладно ещё, если это рекомендации для устранения какой-то конкретной критичной уязвимости. Но мы ведь можем (и, имхо, должны) рекомендовать устанавливать обновления безопасности регулярно и безусловно. Чтобы большая часть уязвимостей исправлялась в этом регулярном процессе, без участия Vulnerability Management специалистов.

И что же делать? Я думаю следующее:

🔸 Риски привнести НДВ с обновлениями всегда есть и будут. Поэтому и существует методика тестирования безопасности обновлений. 😉 Которая должна применяться, как минимум, для зарубежного и опенсурсного ПО. Насколько она реально применяется - пусть будет на совести каждого. 🙂

🔸 Выбор новой версии ПО для исправления конкретной критичной уязвимости лучше оставить на усмотрение IT. Хотят ставить минорную версию, которая исправляет только одну уязвимость, но с меньшей вероятностью влияет на основную функциональность ПО - их право. 🤷‍♂️ Уязвимость исправлена и ладушки.

🔸 Безусловные регулярные обновления ПО до последней версии всё равно считаю правильной и прогрессивной мерой. Риски, что вендора подломят и проведут Supply Chain Attack или вендор сойдёт с ума и сам внесёт зловредную функциональность, всё-таки гораздо ниже, чем риски эксплуатации известных уязвимостей. Чтобы риски были ещё ниже стоит внимательнее подходить к подбору вендоров и мониторить новости об инцидентах с ними, чтобы в случае, если (когда) они будут скомпрометированы, отработать оперативно.

ITшникам не до уязвимостей

ITшникам не до уязвимостей

ITшникам не до уязвимостей. Мне написал подписчик, которого триггернули мои слова в посте про Vulnerability Management как порождение хаоса в IT.

"Почему есть потребность в VM-е? Потому что IT без живительной стимуляции со стороны не могут поддерживать удовлетворительный уровень безопасности инфраструктуры организации. "

Привожу его сообщение:

"У меня есть некоторый опыт работы в ИТ, включая ИБ-шные компании. ИТ нужна не живительная стимуляция со стороны, а ресурсы и нормально простроенные процессы. Я не видел ещё ни одной конторы, в которой бы подразделения ИТ не были бы тотально перегружены (из-за нехватки людей, большого количества задач или неудовлетворительной организации процессов их работы — в частности, недостаточного внимания к автоматизации IT ops.

Потому что в условиях, когда критериями является "чтобы не падало", и чтобы никто не жаловался [на сроки исполнения]", и очередь задач в десятки на одного сотрудника — совсем не до VM.

Вспоминаются слова одного руководителя ИБ-шной компании: "Смотрю я на наше ИТ, и постоянно возникает желание разгонать всех нахер, и нанять других, порасторопнее". В то время как ИТ страдала совсем не от недостатка расторопности — люди херачили днями и ночами."

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

Vulnerability Management как порождение хаоса в IT

Vulnerability Management как порождение хаоса в IT

Vulnerability Management как порождение хаоса в IT. Тема очевидная и несколько избитая. Почему есть потребность в VM-е? Потому что IT без живительной стимуляции со стороны не могут поддерживать удовлетворительный уровень безопасности инфраструктуры организации. 🤷‍♂️

А как бы было хорошо: ITшники сами устанавливают регламент по обновлениям (включая экстренные обновления) и сами следят за его выполнением, сами разбираются в харденинге и внедряют его. А ИБ только периодически проводят аудиты и поражаются насколько же всё грамотно выстроено и работает как отлаженный смазанный механизм. И, со слезами умиления на глазах, закупают ITшникам всякие вкусняшки, поют соками-водами и долго трясут руки героям невидимого фронта. Нет, без шуток. Мой идеальный VM это полное отсутствие VM-а вообще, ввиду его ненужности, ведь безопасность в организации наступает сама, by design, без каких-либо избыточных костылей.

Но вот что-то в реальной жизни так решительно не получается. И чем больше масштаб организации, тем больше хаоса, адища, скверны и пагубы там образуется со временем. Возможно оттого, что цели разные. У кого-то учёт в рублях, а у кого-то в сутках. Когда в IT платят за то, чтобы просто надёжно работало, нужно быть отбитым фанатиком, чтобы ещё и по собственной инициативе постоянно обновлять своё хозяйство для исправления уязвимостей. Сложная задача становится сложной задачей со звёздочкой. И зачастую без какой-либо положительной мотивации, скорее наоборот - втыки за то, что опять что-то отъехало после обновления. И всё равно продолжать это делать. Потому, что "так надо", "так правильно". Мало таких буйных и не надолго их хватает.

Поэтому дорога одна - вниз, в адище и хаос. Из которого, после инцидентов или под воздействием регуляторной дубины, рождается то, что должно с ним как-то бороться - Vulnerability Management. Порождение по природе своей ограниченное, компромиссное и неполное. Ну а что вы хотели? От осинки не родятся апельсинки.

По определению неполная база известных уязвимостей становится отправной точкой для ещё более неполной базы уязвимостей с формализованными детектами. Детектами, которые не всегда могут достоверно найти уязвимость ввиду многообразия способов установки ПО. Затем набор продетектированных уязвимостей о большей части которых неизвестно вообще ничего подвергается анализу и приоритизации: "а ну малыш, давай, попробуй отгадай" какая из них станет трендовой завтра и через какую организацию поломают. 🙂 Чистый кайф.

И, к сожалению, ничего лучшего для борьбы с IT-хаосом пока не придумали. 🤷‍♂️

Полезный AI для Vulnerability Management-а, каким он будет?

Полезный AI для Vulnerability Management-а, каким он будет?

Полезный AI для Vulnerability Management-а, каким он будет? Имхо, работа с ним должна сводиться к генерации приоритезированного потока задач и их выполнения (насколько возможно автоматизированного).

🔸 Скажи мне, VMGPT, на основе данных о нашей инфраструктуре и известных угрозах, какие конкретные задачи необходимо выполнить в первую очередь для повышения безопасности организации и/или улучшения VM-процесса? Эти задачи должны быть достаточно конкретными, например, исправить уязвимость X на хосте Y или раскатать агента для детектирования уязвимостей на хост Z.

🔸 Скажи мне, VMGPT, на основе данных о нашей инфраструктуре, сотрудниках, имеющихся инструментах и формализованных процессах IT и ИБ, как решить конкретную задачу из предыдущего пункта наиболее быстро и эффективно. И, если возможно, выполни эту задачу полностью самостоятельно и напиши по ней отчёт. Например, пропуши нерадивого админа, который не запатчил свои хосты в срок. Или разберись почему агенты не раскатаны на какие-то хосты и дораскати. Или почему есть несоответствие между хостами в VM-е и CMDB.

Человек-аналитик, возможно, справился бы с каждой конкретной задачкой лучше, но человека нужно найти, нанять и зарплату ему платить - а тут очень быстро, условно бесплатно и с приемлемым уровнем качества. То есть +- такой же расклад, как и с другими AI сервисами, которые сейчас активно используются для автоматического перевода, анализа текстов, генерации картинок, музыки и прочего.

Докажи - покажи!

Докажи - покажи! Сгенерил трек в Suno про популярный способ саботажа Vulnerability Management процесса. Который в итоге приводит к утечкам данных и пошифрованной инфре. 🤷‍♂️ В этот раз схалтурил, так что без рифм. 🙂 Кидайте вашим IT-шникам, если заметили, что они с вами в докажи-покажи начали играть. 😉

Мы уже исправили уязвимость, это сканер наверное фолсит. Да мы уже запатчили всё. Это сканер наверное фолсит… Мы уверены в том, что ваш сканер всё время фолсит. А тыыыы…

Докажи - покажи! Докажи - покажи! Докажи нам! Давай - давай!

ОК, уязвимость действительно есть. Да, похоже, уязвимость действительно есть. Но она не эксплуатабельна! Точно, она не эксплуатабельна! Сто пудов не эксплуатабельна! А тыыыы…

Докажи - покажи! Докажи - покажи! Докажи нам! Давай - давай!

Ок, уязвимость в принципе эксплуатабельна. Вроде да, она эксплуатабельна. Но только не у нас! Нет, точно не у нас! Только не в нашей инфре! А тыыыы…

Докажи - покажи! Докажи - покажи! Докажи нам! Давай - давай!

Ок, в нашей инфре эксплуатабельна. Доказали, и в нашей инфре эксплуатабельна. Но это некритичный хост! Даже если сломают - не страшно! Мы точно считаем - не страшно! А тыыыы…

Докажи - покажи! Докажи - покажи! Докажи нам! Давай - давай!

Ладно - ладно, сломают - будет плохо. Потратил кучу времени и сил, и нам доказал, будет плохо. Ты молодец, мы уязвимость эту исправим. Конкретно эту уязвимость исправим. А в остальном ваш сканер наверное фолсит… Так что даваай!

Докажи - покажи! Докажи - покажи! Докажи нам! Давай - давай!

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме "Пентест"): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме Пентест): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе

Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме "Пентест"): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе. Что достаточно расставить агенты по хостам. А те хосты, куда агенты установить нельзя, например сетевые устройства, достаточно сканировать с аутентификацией. Дескать сканы без аутентификации всегда менее достоверны, чем сканы с аутентификацией, и нужны они только для сканирования периметра или первичной инвентаризации сети. На мой взгляд, это не совсем правильно. Сканировать без аутентификации на наличие известных уязвимостей, обязательно нужно, особенно в случае хостов с веб-приложениями.

И связано это именно с особенностями детектирования уязвимостей при сканировании с аутентификацией. Возьмём Linux-хосты. Как правило, VM-вендоры при сканировании Linux-хостов с аутентификацией ограничиваются детектированием уязвимостей в пакетах из официального репозитория Linux-вендора. 🤷‍♂️ Просто потому, что эти уязвимости описываются в общедоступных бюллетенях безопасности или даже в виде формализованного OVAL-контента. Удобно. Научился работать с этим контентом и можно ставить галочку, что Linux-дистриб поддерживается VM-решением. А как насчёт уязвимостей софта, который отсутствует в официальном репозитории Linux-вендора? Вот тут всё сложнее.

Такой софт может быть установлен:

🔹 Из подключенного стороннего репозитория
🔹 Из пакета (вендорского или самосборного) стандартной пакетной системы дистрибутива (deb, rpm), который принесли на хост ручками
🔹 Из альтернативных пакетов для распространения софта (snap, flatpak, appimage и т.д.)
🔹 Из средств распространения модулей (pip, conda, npm и т.д.)
🔹 Из образа контейнера (docker, podman и т.д.)
🔹 Из исходников софта, при этом сборка софта может происходить на том же хосте или собранный софт может быть перенесён в виде бинарных файлов

В идеале, независимо от способа установки софта на хосте, сканер уязвимостей должен его корректно продетектировать, определить его версию, а по версии определить связанные уязвимости. 🧙‍♂️ Но на практике, из-за того что способов установки софта множество, это весьма нетривиальная задача. 🧐

В итоге мы получаем ситуацию: допустим, у нас есть какой-то коммерческий или опенсурсный софт на Linux-хосте (Zabbix, GitLab, Confluence, Jira). Рыская по хосту по SSH этот софт не так-то просто надёжно найти. А при взгляде на хост извне, он ищется тривиально: сканируем порты, находим web-GUI, зачастую на главной странице находим версию и по ней детектируем уязвимости. При этом мы вообще не зависим от конкретного способа установки и запуска софта на хосте. Главное, что мы сам веб-интерфейс приложения видим. 🤩

Такие "внешние" правила детектирования уязвимостей и самим гораздо проще разрабатывать, и открытой экспертизой можно воспользоваться. Фингерпринтинг для получения CPE в сочетании с поиском в NVD по CPE это, конечно, грязный способ. Зато массовый. 😏 И если грамотно подтачивать и фингепринтилку, и правила детектирования по CPE, то и количество фолзов можно уменьшить до приемлемого уровня. А если ещё и добавить валидацию с помощью проверок с попыткой эксплуатации уязвимости (подтянуть nuclei тот же), то значительный набор уязвимостей можно будет детектировать более чем надежно. 😉

В общем, "пентест"-сканирование для определения известных уязвимостей - must have и для внутрянки тоже, особенно для веб-приложений.

Посмотрел выпуск подкаста КиберДуршлаг с Алексеем Лукацким

Посмотрел выпуск подкаста КиберДуршлаг с Алексеем Лукацким

Посмотрел выпуск подкаста КиберДуршлаг с Алексеем Лукацким. У Алексея Викторовича очень необычный взгляд на вопросы Vulnerability Management-а и мастерские формулировки. 👍🙂📝 Отметил для себя 3 темы, которые было бы интересно подробнее разобрать:

🔻 VM и облачные SaaS-провайдеры. Как контролировать, что провайдер имеет адекватный VM-процесс (да и вообще ИБ) у себя, учитывая, что в случае инцидента отвечать будет не провайдер, а клиент-жертва.

🔻 Статьи о гос. измене / шпионаже (УК РФ 275, 276) и репортинг уязвимостей зарубежным вендорам, организациям и базам уязвимостей. Насколько реальна опасность для исследователя, как поступать правильно и безопасно?

🔻VM-вендорам интересно поддерживать не все продукты. Что делать клиентам (навскидку: пушить VM-вендора, пилить свои детекты, выбирать решения с учётом возможностей VM)?

"Патчить абсолютно всё невозможно и безыдейно" меня, конечно, триггернуло. 🙄