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

Qualys представили AI-powered Patch Reliability Score в составе TruRisk Eliminate

Qualys представили AI-powered Patch Reliability Score в составе TruRisk EliminateQualys представили AI-powered Patch Reliability Score в составе TruRisk Eliminate

Qualys представили AI-powered Patch Reliability Score в составе TruRisk Eliminate. Эта фича предназначена для оценки надёжности обновлений до их массового развертывания.

🤖 ИИ оценивает публичные сигналы о патчах (технические обсуждения, отзывы пользователей, сообщения о сбоях и другие индикаторы, появляющиеся после выхода патча) и формирует динамический Patch Reliability скор.

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

🧪 По данным компании, при проверке на наиболее часто откатываемых патчах 2025 года (таких как USN-7545-1, KB5063878, KB5065426, KB5055523, KB5066835) система заранее присваивала им низкую оценку.

Этот скор может использоваться для автоматизации Patch Management-а и митигаций.

Это в тему, что автоматическое устранение уязвимостей реализуемо, но требует тщательной проработки. 😉

Про обновление third-party приложений через платформу оркестрации Windows Update

Про обновление third-party приложений через платформу оркестрации Windows Update

Про обновление third-party приложений через платформу оркестрации Windows Update. Все мы знаем, что системные обновления Windows накатываются удобным и централизованным образом. А вот с обновлением прикладного ПО под Windows от разных вендоров - тут кто во что горазд. 🤪 Приложение могут самообновляться в фоне, могут показывать разнообразные нотификации. Могут ничего не показывать, оставляя отслеживание обновлений пользователям (или админам/VM-щикам организации). 😏

Microsoft решили поменять ситуацию, предложив разработчикам ПО инструмент, через который они могут описывать обновления своих продуктов и требования по их установке: скрипты для скачивания и установки, скрипт для завершения процессов перед установкой, необходимость перезагрузки и т.п. Такие обновления будут предлагаться пользователям к установке так же как и системные обновления Windows.

Концепция выглядит интересно. Другим вендорам ОС, в том числе отечественным, стоит присмотреться. 😉

Patch Management в Vulns.io VM

Patch Management в Vulns.io VM
Patch Management в Vulns.io VM

Patch Management в Vulns.io VM. Попалась на глаза новая раздатка. 🙂 В ней делают акцент на том, что в Vulns.io добавили не просто автопатчилку, а систему управления обновлениями, работающую в некотором процессе:

1. Сбор и отображение информации об обновлениях, исправляющих детектируемые уязвимости.

2. Загрузка обновлений в локальное хранилище с проверкой целостности. Обновления для прикладного ПО под Linux и Windows сейчас скачиваются с сайтов вендоров, но скоро будут скачиваться централизованно из облака Vulns.io. Системные обновления берутся напрямую из MS Updates/WSUS или Linux-репозиториев.

3. Проверка безопасности обновлений и ручной перевод обновления в "доверенное". Проверку нужно выполнять самостоятельно, возможно по методике ФСТЭК.

4. Создание задач на автоматическую установку "доверенных" обновлений.

Актуальный перечень систем и софтов, для которых поддерживается обновление, содержится в файле (раздел "Обновляемое программное обеспечение"). 😉

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

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

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

Я стою на том, что вендору виднее - раз вышло обновление безопасности, значит будь любезен его поставить. Может не прямо 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 не вижу. 😉

По поводу прошедшего вчера мероприятия Qualys по Patch Management-у

По поводу прошедшего вчера мероприятия Qualys по Patch Management-у

По поводу прошедшего вчера мероприятия Qualys по Patch Management-у. В первую очередь хочу поблагодарить Дмитрия и Никиту за компанию, текстовая трансляция с обсуждением удалась. 🙂👍

Понравилось:

✅ Крутой доклад Eran Livne про Patch Management в Qualys. 👍 Особенно про создание связанных задач на патчинг (сначала на тестовом скоупе, а через неделю на полном скоупе) и про возможность изолировать хосты в качестве митигейшена (остаётся доступ только из облака Qualys). Про новый TruRisk Eliminate было тоже интересно.
✅ Adam Gray красиво обосновал необходимость обязательного патчинга (т.к. prevention толком не работает 🤷‍♂️).

Не понравилось:

❌ Большую часть времени докладчики говорили не про Patch Management, а про другие ИБ темы. Хотелось бы большего фокуса.
❌ Тезисы типа "вам не нужно патчить все уязвимости" не могу принять. 🤷‍♂️ Моя позиция: нужно патчить всё. А workaround-ы это хорошо, но это временные костыли ДО полноценной установки патча.

Интерактивчик: во время сегодняшнего мероприятия Qualys в 19:00 я буду делать пометки в чатике VK

Интерактивчик: во время сегодняшнего мероприятия Qualys в 19:00 я буду делать пометки в чатике VK

Интерактивчик: во время сегодняшнего мероприятия Qualys в 19:00 я буду делать пометки в чатике VK. Приглашаю всех выкатиться туда к этому времени. Перемоем косточки Qualys-ам, поугараем над штампами буржуйского ИБ-маркетинга, отметим полезные идеи и фичи. На само сообщество "Управление Уязвимостями и прочее" в VK тоже приглашаю подписаться. Пока это резервная площадка, но что-то мне подсказывает, что довольно скоро она может стать основной. 😏 Все посты туда дублирую и там открыты комментарии.

Qualys представляют TruRisk Eliminate для дополненного Patch Management-а

Qualys представляют TruRisk Eliminate для дополненного Patch Management-а

Qualys представляют TruRisk Eliminate для дополненного Patch Management-а. Не стали Qualys нагнетать интригу вплоть до мероприятия и опубликовали блог-пост с анонсом. Дело оказалось не в иммутабельной инфре, и не в виртуальном патчинге. Если одним словом - это workaround-ы.

На скриншоте TruRisk Eliminate видим отфильтрованный список уязвимостей на активах, критичность уязвимостей в виде QDS, колонки Remediations и Mitigations.

🔹 Remediations - это установка патча или установка патча с переконфигурированием.

🔹 Mitigations - это workaround-ы, нейтрализующие уязвимость без патчинга: изменение ключа реестра, изменение конфига, удаление приложения, блокировка порта, изоляция устройства и т.д.

И есть кнопка для выполнения действия на активе с помощью агента с выбором Remediations/Mitigations опции.

Логичное развитие. Раз дали возможность патчить, чего бы не дать возможность применять workaround-ы. Но сложностей с этим у Qualys будет - атас. 🫣