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

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

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

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

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

Завтра Qualys проводит на BrightTALK большое онлайн мероприятие про Patch Management

Завтра Qualys проводит на BrightTALK большое онлайн мероприятие про Patch Management

Завтра Qualys проводит на BrightTALK большое онлайн мероприятие про Patch Management. Обещают представить концепцию "Patching goes Patchless". Нагнетают интригу, обещают "groundbreaking new strategies". 🤔 Будут продвигать иммутабельную инфраструктуру или виртуальный патчинг? Upd. Не угадал.

Что будет ещё, помимо keynote доклада от CEO Qualys?

🔹 CIS расскажут о том, когда следует устанавливать патчи (и когда не следует), минимизируя перебои в работе бизнеса.
🔹 Доклады от ИБ-компаний. InfoSys расскажут как разобраться с 80–85% критичных обновлений безопасности в течение 4–5 дней. Novacoast накинут докладом "ваши инструменты не работают".
🔹 Клиентские доклады от сотрудников JPMorgan Chase и Signature Aviation (судя по их соцсеточкам 😉).
🔹 2 продуктовых доклада Qualys про улучшение взаимодействия с IT и "remediation beyond patching".

Начало в 9:00 AM PT (19:00 MSK). Идти будет часа 4. Думаю keynote и продуктовые доклады точно стоит заценить, остальное опционально.

Как будем описывать активы в Vulremi?

Как будем описывать активы в Vulremi?

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

{
"asset_id": "important-host1",
"owner": "marketing_department",
"patching_engineer": "johnsmith1",
"patching_rule": "once in a month",
"asset_value": "key",
"asset_type": "server",
"perimeter": false,
"last_scan": "2024-02-06T21:07:27+00:00",
"vulnerabilities":
[
{
"vulnerability_id": "CVE-2024-00001",
"cvss_v3_env": "CR:L/IR:M/AR:M/MAV:N/MAC:L/MPR:N/MUI:N/MS:U/MC:L/MI:L/MA:L",
"related_objects":
[
{
"object_type": "ubuntu_package",
"name": "anacron",
"version": "2.3-38ubuntu1"
}
]
}
]
}

Параметры для описания самого актива

🔹 asset_id - идентификатор актива. Логично было бы использовать для него hostname, но ситуации бывают разные, поэтому не конкретизирую. Возможно это будет id из CMDB-шки.
🔹 owner - ответственный за актив, с которым можно договариваться о регулярных и экстренных обновлениях актива. Обычно какое-то бизнесовое подразделение.
🔹 patching_engineer - тот, кто непосредственно должен обновлять активы. С него нужно спрашивать, если договоренности по регулярным или экстренным обновлениям нарушаются.
🔹 patching_rule - правило регулярного обновления, которое было согласовано с овнером. Если оно нарушается, то спрашиваем с patching_engineer.
🔹 asset_value - ценность актива для злоумышленника. Если, получив доступ к активу, злоумышленник может непосредственно реализовать недопустимое событие, то значит актив целевой (target). Если, получив доступ к активу, злоумышленник может развить атаку на целевой актив, то значит актив ключевой (key). Если и не ключевой, и не целевой, то обычный (ordinary).
🔹 asset_type - тип актива. Critical Infrastructure, Server, Network Equipment, Desktop, Other. Ровно как в методике оценки уровня критичности уязвимости ФСТЭК, примеряемся к использованию. 😏
🔹 perimeter - влияет ли состояние актива на безопасность периметра. Тоже как в методике ФСТЭК.
🔹 last_scan - когда этот актив сканировали на уязвимости в последний раз. Чтобы понимать насколько у нас информация по уязвимостям актуальная. Если нашли активы со старой датой - идём разбираться со сканами.

Параметры для описания уязвимостей на активе

🔸 vulnerability_id - идентификатор уязвимости. CVE. Если нет CVE, то BDU. Если и его нет, то любой уникальный идентификатор уязвимости. По этому идентификатору найдем описание этой уязвимости в объекте типа vulnerability, который я буду описывать позже.
🔸 cvss_v3_env - environmental часть CVSS вектора на случай, если мы захотим поманипулировать через него критичностью уязвимости для данного актива.
🔸 related_objects - объекты актива, связанные с уязвимостью. Опциональная штука, которая может быть использована patching_engineer-ом для того, чтобы понять на что ругается сканер. Если в связанных объектах линуксовый пакет, значит его нужно обновлять и всё будет ок. С другой стороны, там может быть описан не только пакет, но и, например, софт. В этом случае можно будет накрутить логику учёта российский он или нет, а следовательно решать требуется ли тестирование безопасности обновления или не требуется. Но подробнее эту штуку буду расписывать позже, уже после MVP.

Надёжная позиция, которой стоит держаться при общении с IT об установке обновлений безопасности

Надёжная позиция, которой стоит держаться при общении с IT об установке обновлений безопасности

Надёжная позиция, которой стоит держаться при общении с IT об установке обновлений безопасности.

1. То, о чём мы говорим, это сетевой актив (= есть адрес IPv4/IPv6)?

2. У этого сетевого актива есть вендор (вендоры), отслеживающий появление уязвимостей и выпускающий обновления безопасности? Если да, то обновления безопасности должны своевременно тестироваться и устанавливаться. Это требования от вендоров, регуляторов и здравого смысла (cyber hygiene). На всех уровнях: hardware, OS, application. Если такого вендора (вендоров) нет, то актив неподдерживаемый и для него должен быть план вывода из эксплуатации.

3. Процесс Управления Уязвимостями нужен для отслеживания своевременной установки обновлений безопасности. Если актив не поддерживается средствами детектирования уязвимостей необходимо либо искать новые средства, либо выводить актив из эксплуатации.

Когда IT согласны с 3 пунктами можно обсудить какие у них есть проблемы с обновлениями и как им с этим помочь.