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

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

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

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

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

Нужно ли ставить целью снижение количества уязвимостей до нуля?

Нужно ли ставить целью снижение количества уязвимостей до нуля?

Нужно ли ставить целью снижение количества уязвимостей до нуля? В канале у Алексея Лукацкого сегодня про снижение веса как метафору исправления уязвимостей:

"Поэтому не надо ставить целью снижение количества инцидентов или уязвимостей до нуля - это опасно для службы ИБ. Выброшенные на ветер деньги, стресс… 🤔 Нужен баланс, приоритизация и вот это вот все."

Имхо, цель снижения количества уязвимостей до 0 нужно ставить. Но нужно уточнить: каких именно уязвимостей?

❌ Речь не о том, что в инфре не должно быть известных уязвимостей в любой момент времени. Это нереалистично.

✅ Речь о том, что каждая известная уязвимость должна находиться в процессе исправления (планового или приоритетного). Должно быть понимание кто, как и в какие сроки её исправляет. А уязвимостей, на которые мы тупо забили (вообще не продетектили, или продетектили, но посчитали не требующими исправления и т.п.) должно быть 0.

Метафора снижения веса тут не работает. Вес может быть нормальным. Уязвимость всегда ненормальна. И про уязвимость всегда недостаточно информации. Сегодня мы считаем, что это неэксплуатабельная ерунда, а через 3 месяца внезапно начинаем одурело бить в рынду. Ну вот так оно работает. 🤷‍♂️ Невозможно со стопроцентной вероятностью угадать, где и когда оно выстрелит.

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

Так что как по мне - лучше стремитесь к 0 уязвимостей, которые НЕ находятся в процессе исправления. Да, вряд ли этот идеальный результат удастся достичь, но результат будет всяко лучше, чем если успокаивать себя, что все уязвимости исправлять не нужно, а нужно исправлять только самое-самое "красненькое". Объявлять такое за норму это уже, продолжая метафору снижения веса, бодипозитив в самых его гротескных и нездоровых формах. 😉

Как будем описывать активы в 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.

Возвращаюсь к теме простой утилиты для управления исправлением уязвимостей

Возвращаюсь к теме простой утилиты для управления исправлением уязвимостей

Возвращаюсь к теме простой утилиты для управления исправлением уязвимостей. Собираюсь вести работу в рамках проекта Vulremi на GitHub (заводил 3 года назад и пока там пусто).

Что нужно для MVP? Видятся следующие этапы:

🔹 Научиться раскладывать результаты детектирования уязвимостей и данные по инфре в удобные структурки описывающие активы/хосты (назовём их Активы).

🔹 Научиться на основе Активов генерить/обновлять структурки описывающие требования по исправлению уязвимостей определенными ответственными лицами в определенный срок (назовём их Таски).

🔹 Научиться по Таскам делать сводную статистику по ответственным: сколько Тасок на каждом ответственном, сколько из них укладываются по времени, а сколько нет.

То есть берём источник данных об уязвимостях (результаты сканирований), непрерывно обновляем из него Активы, по Активам непрерывно обновляем статус Тасков, ответственных по просроченным Таскам автоматизированно тыкаем палочкой. Профит. 🙂

Периодически у меня возникает идея: а почему бы не сделать простую опенсурсную утилиту для контроля исправления уязвимостей в организации?

Периодически у меня возникает идея: а почему бы не сделать простую опенсурсную утилиту для контроля исправления уязвимостей в организации?

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

На этом этапе требуется перейти из уютного ИБшного мирка к суровой IT-шной реальности. Согласованию (а затем отслеживанию и отстаиванию) договоренностей по регулярным апдейтам и дедлайнов по исправлению супер-критичных уязвимостей. Хорошо, когда у вас все инструменты для этого есть в рамках вашего энтерпрайзного VM-решения, а что если их по каким-то причинам нет или они вас не устраивают? А активов у вас десятки тысяч со множеством групп ответственных. 🤩

Я на самом деле даже несколько раз такое запиливал и оно работало с ощутимой пользой. Но потом начиналось - в проде такое нельзя держать, несерьёзно. 🫣 Нужно делать по красоте, с проработкой сложной архитектуры, многопользовательскими интерфейсами, правильным оптимизированным кодом и всем прочим. Короче, нормальный серьезный проект, а не поделье наколеночное. И это, конечно, справедливо. Однако такой серьезный проект требует серьезных ресурсов, выделенной команды и всё это начинает жутко буксовать и перерождается в нечто совсем иное. 🙂 Может и неплохое, но уже с другим замыслом и принципами.

Мне же хотелось бы, чтобы было примитивно и наглядно. Вот как OVAL/SCAP в части правил детектирования. Казалось бы возня с нелепыми XML-ками, ха-ха. А насколько живучая тема вышла! 🤔

Какие бы принципы я сформулировал:

🔹 Чтобы всё описывалось JSON-файликами: активы, инвентаризационные объекты на активах, уязвимости, таски на исправление.

🔹 Чтобы были простые скрипты, которые эти файлики молотили в автоматическом режиме и отображали текущее состояние процесса в организации.

🔹 Чтобы не было никаких архитектурных и технических ограничений на логику работы с файликами и можно было гибко настроить любой воркфлоу.

🔹 Чтобы с этим можно было поиграться и понять, какие фичи было бы неплохо получить в рамках полноценного "взрослого" VM-решения. Ну или если какой-то небольшой организации без бюджетов и такое зайдет as is для старта или на постоянку - ну круто. 🙂

Так вот, как считаете, имеет смысл поописывать и покодякать такой наколеночный "игрушечный" Vulnerability Remediation? 🙂