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

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

1 комментарий

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

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

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

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

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

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

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

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

БОСПУУ и светофоры

1 комментарий

БОСПУУ и светофоры

БОСПУУ и светофоры. То, что вы видите на схеме БОСПУУ это характеристики нормального функционирующего Vulnerability Management процесса. Есть адекватный поток продетектированных уязвимостей, он обрабатывается, задачи на устранение уязвимостей заводятся, выполнение задач отслеживается.

А что, если у вас, как в посте Алексея Лукацкого, 10% активов не покрыты детектами? И, более того, эти активы не оценены и вы не знаете есть ли там целевые или ключевые системы. Это значит, что нормального VM-процесса у вас нет. 🤷‍♂️ И ваши красивые дашборды не отображают реального состояния инфры. Можно, как описывается в том же посте, спрятаться за светофорчик: 90% есть, красим в зелёненький. 🚦👌 Но это самообман и обман руководства организации. Заканчивается это плохо. В случае инцидента светофорчик вас не спасёт.

Рекомендую не приукрашивать положение дел, а приводить VM-процесс к нормальному функционирующему состоянию, которое подразумевает контроль всех активов и всех уязвимостей.

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

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. Схема