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

Обновил схему Базовой Оценки Состояния Процесса Управления Уязвимостями (БОСПУУ)

8 комментариев

Обновил схему Базовой Оценки Состояния Процесса Управления Уязвимостями (БОСПУУ)

Обновил схему Базовой Оценки Состояния Процесса Управления Уязвимостями (БОСПУУ). Теперь там 4 компонента:

🔻 Адекватность используемых решений по детектированию уязвимостей
🔻 Анализ уязвимостей и заведение задач на устранение уязвимостей 🆕
🔻 Охват инфраструктуры, работа с активами и ответственными за устранение уязвимостей
🔻 Отслеживание выполнения SLA по задачам на устранение уязвимостей для скоупов активов

По сравнению с версией 0.0.5, разнёс работу с активами/ответственными и анализ уязвимостей/заведение задач на исправление. Подрихтовал формулировки, чтобы было меньше неоднозначного. Сознательно убрал про сканирование сетей - это укладывается в "нет активов без регулярных проверок на уязвимости".

Это всё ещё драфт, но вроде выглядит уже более-менее прилично и кажется, что всё основное в VM-процессе охватывает. Можно потихоньку отвечать на критику от Алексея Лукацкого. 😉

Если видите недочёты - не стесняйтесь, пишите в личку @leonov_av. 🙂

В непожатом виде

БОСПУУ и/или результативный подход? Как правильно заметил Алексей Лукацкий в сегодняшнем посте, я начал формулировать своё видение оценки состояния VM-процесса в ответ на его материалы про измерение результативности VM-решения (поломают нас или нет) с использованием временных оценок Time to Notify/eXploit/Patch/Eliminate и т.д

Добавить комментарий

БОСПУУ и/или результативный подход? Как правильно заметил Алексей Лукацкий в сегодняшнем посте, я начал формулировать своё видение оценки состояния VM-процесса в ответ на его материалы про измерение результативности VM-решения (поломают нас или нет) с использованием временных оценок Time to Notify/eXploit/Patch/Eliminate и т.д

БОСПУУ и/или результативный подход? Как правильно заметил Алексей Лукацкий в сегодняшнем посте, я начал формулировать своё видение оценки состояния VM-процесса в ответ на его материалы про измерение результативности VM-решения (поломают нас или нет) с использованием временных оценок Time to Notify/eXploit/Patch/Eliminate и т.д.

Тема интересная, но я и из первого поста, и из отдельного поста про TTE не понял конкретный механизм как это считать. 🤔 Для каждой CVE и актива организации? Так-то фиг угадаешь, когда конкретная уязвимость эксплуатироваться начнёт. А если это "общая температура по больнице", то какой в ней смысл? Пока это выглядит утопично и требующим детализации.

В БОСПУУ же я собираю конкретные измеримые вещи, которые точно приведут к улучшению VM-а. И повысят шансы успешного противодействия злоумышленникам.

Насколько? Это как раз и можно попробовать прикинуть с помощью результативного подхода. Но, имхо, это опциональное дополнение, не база.

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ): предварительная схема по текстовому описанию

3 комментария

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ): предварительная схема по текстовому описанию

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ): предварительная схема по текстовому описанию. Конечно, требуется дальнейшая детализация и расширение. Мне в первую очередь интересна оценка используемых средств детектирования. 😎

Upd. Обновленная версия 0.0.6

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ)

2 комментария

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ)

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ). Как правильно отслеживать и развивать Vulnerability Management процесс? Имхо, нет единственно правильного способа. Если уязвимости в инфраструктуре своевременно исправляются, аудиторы вас нахваливают, а пентестеры грустят, значит всё норм. 👍 Но некоторые свои соображения я сформулирую под названием БОСПУУ. 😉

Общая оценка состоит из 3 компонентов:

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

🔸 Оценка охвата инфраструктуры VM-процессом (несканируемые активы и сети, активы без ответственных, активы без SLA по устранению уязвимостей, уязвимости без тасков)

🔸 Оценка выполнения SLA по патчингу для скоупов активов. Каждый скоуп разбиваем на группы активов по критичности: целевые, ключевые, обычные. Для каждой группы отслеживаем выполнение SLA по плановому и приоритетному исправлению уязвимостей.

upd. Схема

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

4 комментария

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

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

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

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

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

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

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

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

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

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

Добавить комментарий

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

Аксиома обновления до последней версии ПО. В комментариях к посту про 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шникам становится совсем не до уязвимостей. И не до информационной безопасности в целом. 🤷‍♂️