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

На Anti-Malware вышла статья Алексея Дашкова, директора Центра продуктового менеджмента R-Vision, "Vulnerability management: как выстроить процесс управления уязвимостями правильно"

На Anti-Malware вышла статья Алексея Дашкова, директора Центра продуктового менеджмента R-Vision, Vulnerability management: как выстроить процесс управления уязвимостями правильно

На Anti-Malware вышла статья Алексея Дашкова, директора Центра продуктового менеджмента R-Vision, "Vulnerability management: как выстроить процесс управления уязвимостями правильно". R-Vision давно занимаются VM-темой, заявляют 10 лет, но раньше эта функциональность в решениях R-Vision не была основной, а детект уязвимостей реализовывался сторонними сканерами. В этом году они презентовали специализированный продукт R-Vision VM с собственными детектами. Статью можно рассматривать в контексте маркетинговой активности по продвижению нового продукта. 😉 Я прочитал статью и сделал выжимку.

1. Уязвимости присутствуют почти в любой инфраструктуре, их много, эксплуатация может привести к серьёзным последствиям.
2. Западные вендоры оставляют компании в РФ без поддержки и обновлений, поэтому требуется тщательная проработка VM-процесса.
3. В большинстве случаев уязвимости вызваны ошибками программирования, настройки или проектирования.
4. Важность VM подчеркивается в СТО БР ИББС, ISO 27002:2022, CIS Critical Security Controls, PCI DSS, руководстве по организации VM процесса ФСТЭК и др.
5. Для небольшой компании можно детектировать уязвимости сканером, а ставить задачи IT вручную силами одного ИБшника. С увеличением количества информационных систем и расширением IT-инфраструктуры требуется VM-процесс.
6. Частые трудности VM-процесса: контроль изменений IT-инфраструктуры, приоритизация уязвимостей, учёт компенсирующих мер, обоснование необходимости исправлять уязвимости для IT, отслеживание статусов/сроков устранения уязвимостей, мониторинг процесса и генерация отчётности.
7. Цикл Управления Уязвимостями: инвентаризация, выявление, приоритизация, устранение, контроль. Рекомендуется внедрять этапы последовательно.
8. Инвентаризация. Получить информацию об активах из системы мониторинга IT-инфраструктуры или CMDB, объединить активы в группы, определить ответственных, связать с подразделениями и бизнес-процессами (и др. типами используемых "нематериальных активов"), понять критическую значимость активов.
9. Выявление. С помощью сканера уязвимостей или вручную (red teaming). Выполнять постоянно.
10. Приоритизация. Можно использовать CVSS, алгоритм НКЦКИ (от меня: скорее нет - он для принятия решения о патчинге западного ПО), методику оценки критичности ФСТЭК. CVSS не учитывает эксплоиты (от меня: temporal учитывает, не учитывает активную эксплуатацию). Базовые варианты приоритизации (устранения): только критичные уязвимости, только уязвимости с эксплоитами, только удалённо эксплуатируемые, только на критичных активах. Можно комбинировать.
11. Устранение. Приведена схема. Ключевой аспект - взаимодействие с IT. Заключается в создании задач вручную и автоматизированно (от меня: с тасками аккуратнее). Каждая уязвимость должна проходить процесс обработки с оценкой применимости (от меня: может вырождаться в докажи-покажи). Обновления должны тестироваться. Если нельзя обновить, компенсирующие меры: переконфигурирование, ограничение использования ПО/оборудования, резервирование серверов/сет. оборудования, мониторинг эксплуатации уязвимости, СЗИ (firewall, антивирус).
12. Контроль. Оцениваем работу IT и вырабатываем решения по улучшению VM-процесса. Проверка через повторное сканирование или через ручную эксплуатацию. Формируйте отчётность.
13. Цель VM - выявить и устранить проблемы в защите до их превращения в угрозы для бизнеса.
14. К организации VM-процесса можно подходить по-разному, главное, чтобы уязвимости своевременно устранялись и злодеи не смогли их использовать.
15. При позиционировании R-Vision VM делают акцент на построение полного цикла VM и возможность строить процесс "для нескольких организаций в одной системе" (для сервис-провайдеров?).

Статья понравилась. 👍 Единственное, к сожалению, не увидел пропаганды безусловного регулярного патчинга. Про детекты маловато, особенно про то, что делать если для каких-то систем автоматических детектов нет. Про обработку и таски я по тексту отметил. Про трендовые уязвимости тоже не было, но думаю будет, когда появится такая функциональность.

Способ затормозить Vulnerability Management процесс "докажи, что эксплуатабельно!"

Способ затормозить Vulnerability Management процесс докажи, что эксплуатабельно!

Способ затормозить Vulnerability Management процесс "докажи, что эксплуатабельно!" Этот способ ещё более универсальный, чем предыдущий. Заключается в том, что IT постоянно требуют от VM-щика что-то доказывать перед тем как приступить к непосредственному исправлению уязвимостей. Причём после каждого успешного доказательства IT могут отойти на новый "рубеж обороны".

1. Мы уже исправили уязвимость, сканер наверное фолсит. VM-щику предлагается доказать, что уязвимость действительно присутствует и сканер не фолсит.

2. Да, эта уязвимость есть, но она неэксплуатабельная. VM-щику предлагается найти эксплоит и провести демонстрацию.

3. Да, эта уязвимость в принципе эксплуатабельная, но в условиях нашей инфраструктуры она неэксплуатабельная. VM-щику предлагается доказать эксплуатабельность уязвимости, при этом не навредив инфраструктуре.

4. Уязвимость на хосте, который не является критичным, и даже если он будет скомпрометирован, то ничего страшного не произойдет. VM-щику предлагается продемонстрировать критичные последствия компрометации уязвимого хоста.

А что в итоге? Допустим, потратив кучу времени и сил VM-щик добивает своего. Статус уязвимости подтверждается. IT-шники торжественно фиксят эту уязвимость. 🥳

ОДНУ. А что с остальными сотнями и тысячами? А также. Мыло-мочало, начинай сначала!

Вместо того, чтобы поднимать реальный уровень защищённости VM-щик занимается бесконечными недопенстестами. А IT-шникам в это время хорошо, пока VM-щики заняты доказыванием чего-то, их не допекают необходимостью постоянно патчиться. 😏

Как с этим бороться? Имхо, наиболее действенный способ поставить вопрос так:

🔸 Мы специалисты по уязвимостям, а вы специалисты по эксплуатации.
🔸 Мы вам говорим, что уязвимость критична и требует исправления, основываясь на информации от вендора и своей экспертизе, которой вы, объективно, не обладаете.
🔸 В случае инцидента с эксплуатацией этой уязвимости спрос за неисправленную вовремя уязвимость будет с нас, с VM-щиков, а то, что у вас было какое-то другое мнение по поводу этой уязвимости вообще никого волновать не будет, т.к. это не ваша область ответственности и не ваша специальность.
🔸 Мы вам задачу на исправление поставили и доказывать дополнительно ничего не намерены. Не будете выполнять задачу - ваши проблемы, но в случае масштабного инцидента именно вы можете попасть под 274 УК РФ ("Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей"), т.к. по правилам необходимо устанавливать обновления безопасности. 🤷‍♂️

Жёстко? Пожалуй. Я вообще за то, чтобы как-то по-хорошему договариваться. Но если пошла игра в "докажи-покажи", то тут уже по-хорошему становится сложно и нужно это сразу пресекать.

Способ затормозить 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 операционок, оперативному исправлению критичных уязвимостей].