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

Способ затормозить Vulnerability Management процесс "ты как челобитную царю подаёшь?!"

Способ затормозить Vulnerability Management процесс ты как челобитную царю подаёшь?!

Способ затормозить Vulnerability Management процесс "ты как челобитную царю подаёшь?!" 👑 Несколько разовью тему с офигиванием IT-шников от VM-а и того, что они могут придумать в ответ. Данный способ простой, эффективный и без формальных изъянов. Подходит как самая первая мера. ITшники говорят, что, разумеется, они готовы обновлять системы, но для того, чтобы заниматься этим на потоке, им необходимо, чтобы информация об обнаруженных уязвимостях доводилась до них несколько иначе, чем сейчас:

🔻 В виде тасков в таск-треккере (1 уязвимость - 1 хост, сгруппированные по уязвимостям, сгруппированные по хостам)
🔻 В виде REST API вызовов (всё сразу, по хосту, по уязвимости)
🔻 В виде выгрузок на гитлабе, файловой шаре, в монге, кафке (CSV, XML, JSON, YAML)

Требуемое описание уязвимости может содержать в себе любой набор полей, включая, например перевод описания уязвимости. Мы же российская компания - давайте нам всё на русском. 😏 И прямые ссылки на патчи, пожалуйста! И команду для полного обновления хоста! И команду для частичного обновления хоста (только самое критичное)! И прямые ссылки на PoCи (непонятно зачем, но тоже пусть будет - нам интересно 🙂)!

Конкретные требования значения не имеют, т.к. весь расчет на то, что пока вы будете возиться с тасками/выгрузками в том виде, в котором это захочется IT (а каждому отделу может хотеться разного), вы не будете их доставать с патчингом. А после можно будет придумать что-нибудь ещё. 💡

Кроме того, в случае тасков в таск-треккере, они наглядно смогут показать, что в итоге получилась какая-то абсолютно неюзабельная ерунда. Работать вручную с тысячами автогенеренных тасок по уязвимостям будет, естественно, невозможно. Сразу что ли было непонятно, товарищи VM-щики?! 🙃 Но это будет потом, после месяцев потраченных на встречи, обсуждения, согласования и разработку. 😏

Что с этим делать? Конечно, нужно стараться предоставлять коллегам из IT данные по уязвимостям в удобном для них виде. Но также нужно чётко отслеживать, когда они начинают юлить и водить вас за нос. В этом случае следует говорить твёрдое "нет, работайте с тем, что есть" и эскалироваться в случае их отказа работать по процессу.

Постоянное офигивание ITшников это нормальное следствие работающего Vulnerability Management процесса

Постоянное офигивание ITшников это нормальное следствие работающего Vulnerability Management процесса

Постоянное офигивание ITшников это нормальное следствие работающего Vulnerability Management процесса. В чём вообще задача процесса Управления Уязвимостями? В том чтобы в инфраструктуре не было критичных уязвимостей и ими не мог воспользоваться злоумышленник. Именно за это VM-щику платят деньги и за это он отвечает (при плохом раскладе вплоть до уголовки 🤷‍♂️). А для того, чтобы таких уязвимостей в инфраструктуре не было, их нужно (сюрприз-сюрприз!) исправлять. 🙂 Чаще обновлениями, реже переконфигурированием.

Если уж в организации есть какой-никакой процесс управления активами, то покрыть эти активы детектами и открыть бесконечный поток новых обнаруженных уязвимостей дело выполнимое. Насколько мощным будет этот поток? Если брать совсем минимум, то с Patch Tuesday обязательно прилетит KB-шная RCE-шка в Windows ядре или стандартном компоненте, а также RCE в Linux-овом ядре или стандартной утилите. По сетевым устройствам возможно пореже - раз в 2 месяца. Вот и считай - ежемесячное обновление всех Linux/Windows хостов и двухмесячное для всех сетевых устройств. И это с необходимостью эти обновления тестировать перед накаткой. 👨‍🏫 Это минимум!

Класс, да? Каждый админ/девопс будет просто счастлив открывающимся перспективам дополнительно свалившейся на него со стороны ИБшников работы! 🙂 Как и его руководители вплоть до CIO/CTO. И будьте уверены, что они приложат все возможные усилия и все доступные меры корпоративной борьбы, чтобы этого замечательного VM-процесса в итоге не случилось. Не говоря уж о таких мелочах как разнообразные "словесные интервенции". 📣😏

Крепись, VM-щик! Не позволяй выхолостить процесс!

Посмотрел подкаст двух Александров Герасимовых про Vulnerability Management

Посмотрел подкаст двух Александров Герасимовых про Vulnerability Management. Больше контента по VM-у хорошего и разного! 👍 Сгруппировал для себя некоторые тезисы в части VM-а для инфраструктуры. По VM для приложений там тоже было, но мне это не так близко и я отметил, только то, что необходимо интегрировать SAST/DAST/SCA в процессы разработки и деплоя. И чтобы были security approver-ы. Не поспоришь.

По инфраструктуре:

1. Пока не выстроены базовые процессы, такие как инвентаризация активов, сегментация сети, patch management (регулярные обновления), заниматься Vulnerability Management-ом рановато. Нужно понимать какие есть активы, кто эти активы сопровождает, что эти активы из себя представляют (на уровне операционной системы и на уровне ПО), какие активы являются для организации критичными (Mission Critical, Business Critical, Office Productivity). В зависимости от этого настроить риски, недопустимые события, SLA по исправлению для типов активов и критичности уязвимостей, модель угроз ИБ.

2. Сканирования инфраструктуры недостаточно для VM-процесса. Безопасники должны выступать контролерами над уязвимостями: реагировать на критичные 0day уязвимости, отслеживать выполнение циклов регулярно патчинга со стороны IT. У актива должен быть функциональный администратор, бизнес-владелец и технический администратор. Накатывает патч технический администратор, через него идёт взаимодействие и он ответственен за патчинг. ИБ выступает как контроль и руками ничего не делает. Перед установкой патчи должны тестироваться, чтобы работа не нарушалась. При невозможности обновления используем компенсирующие меры (в т.ч. виртуальный патчинг).

3. VM на основе open source, какие могут быть проблемы? Сканеры имеют ограниченную пропускную способность, необходимо масштабировать сканеры и опредялять скоуп серверов, которые можно покрыть одним решением. Должен быть единый центр управления для разбора отчётов. Нужно понимать какие активы есть в организации и есть ли у нас средства детектирования под все типы активов (например, Oracle, российские ОС или сетевые устройства). От меня: основная часть VM-а это средства детектирования уязвимостей. Если вы уверены, что можете покрыть всю инфраструктуру адекватными детектами уязвимостей с помощью бесплатного средства - замечательно. Но постарайтесь это проверить, скорее всего обнаружите активы для анализа которых вам понадобится коммерческое решение.

4. Важно, чтобы VM-продукты имели возможности по интеграции. Для снижения риска утечек паролей из VM-решения, лучше организовывать доступ к кредам для безагентного сканирования через системы а-ля CyberArk. Для отслеживания выполнения заявок на исправление уязвимостей можно использовать интеграцию с SOAR и IRP системами.

Awillix делают периметровый сервис Continuous vulnerability monitoring (CVM), считают это очень востребованной темой. От меня: периметровые сервисы это очень конкурентная область. Со стороны клиента важно оценивать качество детектирования, хоть делать это, как правило, непросто.

На Positive Hack Days я в этом году не выступал (не считая пары слов на награждении), зато буду выступать на Positive Customer Day в четверг 22 июня

На Positive Hack Days я в этом году не выступал (не считая пары слов на награждении), зато буду выступать на Positive Customer Day в четверг 22 июня. Доделал слайды для доклада "Управление Уязвимостями и методики ФСТЭК: оценка критичности, анализ обновлений, процесс". 😇 Доклад будет по мотивам постов про нормативку. Также подсвечу CVSS 4.0 и ОСОКу. В части руководства по VM-процессу кратко рассмотрю 3 вопроса, которые меня больше всего волнуют:

1. Окончательность решения по статусу уязвимости и способу исправления. Здесь есть важные изменения между проектом руководства и релизом. 😉
2. Качество детекта и полнота покрытия активов.
3. Безусловный процесс регулярного патчинга.

Нашёл идеальный головной убор для созвонов с овнерами систем

Нашёл идеальный головной убор для созвонов с овнерами систем

Нашёл идеальный головной убор для созвонов с овнерами систем. 😆 Несите ответственность [за поддержание вашей IT-инфраструктуры в безопасном состоянии], следуйте правилам [по регулярному обновлению хостов, миграции с EOL операционок, оперативному исправлению критичных уязвимостей].

Посмотрел карту компетенций специалиста по ИБ от Positive Technologies

Посмотрел карту компетенций специалиста по ИБ от Positive TechnologiesПосмотрел карту компетенций специалиста по ИБ от Positive TechnologiesПосмотрел карту компетенций специалиста по ИБ от Positive Technologies

Посмотрел карту компетенций специалиста по ИБ от Positive Technologies. Что там с VM-специалистами? Карту презентовали 13 марта, но мне она только сейчас на глаза попалась. К сожалению, по PDF-ке нельзя искать, поэтому приходится смотреть только глазками.

Есть 4 специализации как-то связанные с уязвимостями:
- "Аналитик по оценке уязвимостей (пентенстер)" в группе "Мониторинг событий ИБ и реагирование на события ИБ"
- "Аналитик данных в области эксплуатации уязвимостей информационных систем" в группе "Аналитика ИБ"
- "Аналитик данных об уязвимостях эксплуатируемого ПО (разведка)" в группе "Аналитика ИБ"
- "Аналитик данных об уязвимостях эксплуатируемой сетевой инфраструктуры (разведка)" в группе "Аналитика ИБ"

2 последние специализации можно было бы определить как Vulnerability Intelligence, но обязанности там какие-то совсем загадочные. Что-то на редтимовском видимо. 🙂

В целом, специальность, которая находится в Мониторинге (фактически SOC-овская тема) как основа для специализации VM-щика выглядит норм. Но очень смущает приписка "пентестер". Потому что VM и пентест это вещи из разных вселенных. Пентестеру важно проломить хоть как-нибудь, он весь про реальную эксплуатацию здесь и сейчас. VM-щик работает с неполной информацией и для него наличие эксплоита это один из множества факторов.

Поэтому я бы сделал так:

1. Приписку "пентестер" перенес в специальность "Аналитик данных в области эксплуатации…"
2. Обязанности "Измеряет эффективность многослойной архитектуры защиты" тоже перенес бы в специальность "Аналитик данных в области эксплуатации…". Оценивать эффективность EDR-ов тоже пентестерская тема.
3. "Аналитик по оценке уязвимостей" переименовал бы в "Специалист по управлению уязвимостями". Если есть специалист по реагированию на инциденты, то чего бы не быть специалисту по управлению уязвимостями. 😉
4. Добавил бы этому "Специалисту по управлению уязвимостями" обязанностей по работе с уязвимостями в рамках руководства ФСТЭК: мониторинг известных уязвимостей, оценка применимости, оценка критичности уязвимостей, определения методов и приоритетов устранения, постановка задач на устранение, контроль устранения. Также добавил бы того, что нет в этом руководстве, но что критично: оценка качества детектирования уязвимостей средствами анализа защищенности и оценка покрытия инфраструктуры организации VM-процессом.
5. Обязанности "Выполняет оценку систем и сетей…" дополнил бы фразой "в части процесса управления уязвимостями", а то слишком общо получается и напоминает уже IT-аудит.

И вот в таком виде можно было бы жить. 🙂

Руководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению Уязвимостями. Что изменилось от проекта к релизу. Часть 2. Что определяет руководство?

Продолжаем увлекательное сравнение. Видим в Общих положениях новый пункт 1.2.

"Руководство определяет состав и содержание работ по анализу и устранению уязвимостей (далее – управление уязвимостями),"

Отмечаем: "управление уязвимостями" = "анализ и устранение уязвимостей" ❗️

"выявленных в

программных,
программно-аппаратных средствах"

Ага, вот куда ПО и ПАС из названия документа переехали. ПО и ПАС относящихся к чему?

"информационных систем,
информационно-телекоммуникационных сетей,
автоматизированных систем управления,
информационно-телекоммуникационных инфраструктурах [м.б. инфраструктур?] центров обработки данных, на базе которых функционируют эти системы и сети (далее – информационные системы)."

Т.е., если у вас есть ИС, ИТС, АСУ, центр обработки данных - будьте любезны внедрить VM для ПО и ПАС. 😉👍

Часть 1