Архив метки: БОСПУУ

Уязвимости Шрёдингера и безусловный патчинг

Уязвимости Шрёдингера и безусловный патчинг

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

Я стою на том, что вендору виднее - раз вышло обновление безопасности, значит будь любезен его поставить. Может не прямо ASAP, может с задержкой на недельку-другую ("patch may be delayed" как пишут в ISA/IEC TR 62443-2-3 – 4.1), но НЕ ДОЛЖНО БЫТЬ опции вообще его не ставить только потому, что исправленная уязвимость выглядит как некритичная. Каждая продетектированная уязвимость должна находиться в процессе устранения (планового или приоритетного). Во всяком случае нужно к этому стремиться. 😉

А почему я так считаю, хотя сам делаю утилиту для приоритизации уязвимостей и участвую в определении трендовых уязвимостей? Пчёлы против мёда? 🐝🍯 К сожалению, мир уязвимостей так устроен, что о большей части из них мы не знаем практически ничего, кроме небольшого абзаца текста. 🐈 Кот Шрёдингера в коробке одновременно и жив, и мёртв. А у нас уязвимость одновременно и критичная эксплуатабельная, и нет. 🤷‍♂️ До момента пока не появятся детали: write-up, эксплоит, подтверждения эксплуатации вживую.

Далеко ходить не нужно, смотрим августовский Patch Tuesday с прошлой недели:

🔻 Вот Remote Code Execution - Windows TCP/IP IPv6 (CVE-2024-38063), от которой все на ушах стоят и ждут подробностей.

🔻 А вот Security Feature Bypass - Windows Mark of the Web "Copy2Pwn" (CVE-2024-38213), которую, по данным ZDI, запатчили в июне, а сообщили о ней только в августе. Вот так и принимай решение на основе данных об уязвимостях, когда вендор о них даже не сообщает, а исправляет тихонько. 😏

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

В упомянутой Алексеем Лукацким TSA Security Directive Pipeline-2021-02D в III.E.1 на 7 странице так прямо и написано, что необходимо иметь Patch Management стратегию, которая гарантирует, что все критические системы запатчены:

"A patch management strategy that ensures all critical security patches and updates on Critical Cyber Systems are current"

И только если установка патча ведёт к деградации операционных возможностей (III.E.3, стр.8), тогда нужно исправлять уязвимость workaround-ами с подробным описанием почему мы применяем такие экстраординарные формы митигации (ну и параллельно запрашивать вендора, что это за фигня с патчами, которые функциональность оплаченную портят):

"If the Owner/Operator cannot apply patches and updates on specific Operational Technology systems without causing a severe degradation of operational capability to mect necessary capacity, the patch management strategy must include a description and timeline of additional mitigations that address the risk created by not installing the patch or update."

А как же уязявимости CISA KEV? Где-то написано, что нужно патчить только их? Нет, написано, что список этих уязвимостей нужно учитывать при приоритизации исправления (III.E.2, стр.7):

"2. This strategy required by Section III.E.1. must include:

b. Prioritization of all security patches and updates on CISA’s Known Exploited Vulnerabilities Catalog."

И я соглашусь, что CISA KEV-овские уязвимости нужно исправлять раньше других (понимая, что они туда могут попадать с большой задержкой). Как и с тем, что патчи нужно катать не абы как, а после тестирования и в соответствии с рекомендациями из NIST-800-82-r3 и IEC TR 62443-2-3, которые Алексей Лукацкий перечислил в своём посте. Перечень вполне толковый. 👍

В общем, приведённые в посте документы только укрепили меня в моей позиции. Противоречий моей позиции и указанных best practicies не вижу. 😉

Тоже сделал мемчик с крутым Юсуфом Дикечем

Тоже сделал мемчик с крутым Юсуфом Дикечем

Тоже сделал мемчик с крутым Юсуфом Дикечем. 😅

🔹 Каждая существующая в инфраструктуре уязвимость должна быть продетектирована.
🔹 Для каждой продетектированной уязвимости должна быть заведена задача на исправление.

Это суровая база. А когда вам говорят, что этого можно не делать, потому что есть какой-то супер-современный инструмент оценки уязвимостей, к этому стоит относиться со скепсисом. 😉

Защита на 100%?

Защита на 100%?

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

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

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

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

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

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

В целом, речь, конечно, не идёт ни о каком достижении 100% защиты, а об избежании стопроцентного решета, которое возникает, если Vulnerability Management-ом (и информационной безопасностью вообще) не заниматься. 🤷‍♂️

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее

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

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

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

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

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

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

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

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

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