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

В продолжение темы с R-Vision VM

В продолжение темы с R-Vision VM

В продолжение темы с R-Vision VM. 28 сентября, то есть уже завтра, R-Vision проводят конфу R-EVOlution Conf 2023 (игра слов в том, что EVO - это название их экосистемы продуктов), на которой будет как минимум 3 выступления/активности непосредственно связанных с R-Vision VM:

🔹 11:30-12:30 R-Vision VM - новый подход к управлению уязвимостями. Название интригующее. 😇
🔹 14:30-15:10 R-Vision VM - реальный кейс от заказчика. Т.к. докладывается здесь Олег Кусеров, директор по ИБ НРД (Национальный расчетный депозитарий), то можно предположить о каком заказчике пойдет речь.
🔹 16:05-17:05 Интерактивный круглый стол нa тему SIEM/VM.

Я зарегался. Планирую заслушать живую трансляцию или в записи и затем отрефлексировать. 😉

На 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 и возможность строить процесс "для нескольких организаций в одной системе" (для сервис-провайдеров?).

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

Прожектор по ИБ, выпуск №4 (24.09.2023)

Прожектор по ИБ, выпуск №4 (24.09.2023). Записали вчера очередной эпизод, состав тот же:

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

0:35 Как зашёл прошлый эпизод
2:08 Лев и Максим делятся впечатлениями от Kazan Digital Week
7:06 На какие мероприятия по ИБ мы ходим
11:06 Приостановка сертификата ФСТЭК на Dr.Web Enterprise Security Suite
19:04 Cisco покупает Splunk
25:59 Про RCE уязвимость BDU:2023-05857 в модулe landing CMS "1С-Битрикс: Управление сайтом".
30:02 Новые подробности инцидента с FDM и скрипт для детекта
32:21 Занятные моменты детектирования Linux уязвимостей на примере CVE-2022-1012, RPM-based дистрибутивы и импортозамещение
44:02 Прощание от Mr. X

Занятный кейс, который вы можете показать своему VM-вендору, конкретно специалистам по детекту уязвимостей Linux

Занятный кейс, который вы можете показать своему VM-вендору, конкретно специалистам по детекту уязвимостей Linux

Занятный кейс, который вы можете показать своему VM-вендору, конкретно специалистам по детекту уязвимостей Linux. Есть уязвимость ядра Linux CVE-2022-1012. Вопрос: вы можете продетектировать эту уязвимость в CentOS/RedHat 7?

Уловка в том, что VM-вендоры, как правило, детектируют уязвимости на основе бюллетеней безопасности Linux-вендоров. Т.е. они могут продетектировать только те уязвимости, для которых уже есть фиксы и понимание какие версии пакетов уязвимы. А для этой уязвимости RedHat пишут, что да, она аффектит дистриб, но они не будут исправлять её в CentOS/RedHat 7. Можно было бы предположить, что 7ая версия, наверное, уже EOL. Но нет, для 7ой версии EOL наступит только в июле 2024 года.

Имеем уязвимость, которая

1. Присутствует в ещё поддерживаемой версии ОС.
2. Не может быть исправлена установкой обновления от Linux-вендора.
3. Не может быть продетектирована, если только VM-вендор специально не озаботился детектом "Will not fix" уязвимостей.

Про RCE уязвимость BDU:2023-05857 в модулe landing CMS "1С-Битрикс: Управление сайтом"

Про RCE уязвимость BDU:2023-05857 в модулe landing CMS 1С-Битрикс: Управление сайтом

Про RCE уязвимость BDU:2023-05857 в модулe landing CMS "1С-Битрикс: Управление сайтом".

1. СТРАШНО. Позволяет удаленному злоумышленнику "выполнить команды ОС на уязвимом узле, получить контроль над ресурсами и проникнуть во внутреннюю сеть". CVSS 10/10. Обновляйте модуль до 23.850.0 или отключайте.
2. В описании пишут "1С-Битрикс: Управление", без "сайтом". Видимо ошиблись. 🤷‍♂️ А коллеги из других каналов копипастят as is. 🙂
3. Где бюллетень вендора? Судя по другим уязвимостям, приводится ссылка только на страницу "История версий". В истории версий для модуля landing значится только "v23.850.0 2023-09-14 Критическое обновление безопасности, вносит улучшения в защиту модуля. Рекомендуется к немедленной установке". Если действительно так, то не круто. Бюллетени должны быть! Как и автоматическое обновление.
4. Часто начали говорить о БДУ-шках без ссылок на CVE, заметили? Идём к состоянию: у вас свои продукты/уязвимости, а у нас свои. Общее только opensource.

С маркетинговыми сравнительными отчётами по Vulnerability Management решениям то пусто, то густо

С маркетинговыми сравнительными отчётами по Vulnerability Management решениям то пусто, то густоС маркетинговыми сравнительными отчётами по Vulnerability Management решениям то пусто, то густо

С маркетинговыми сравнительными отчётами по Vulnerability Management решениям то пусто, то густо. Одновременно подъехали:

🔻 GigaOm Radar Report for Continuous Vulnerability Management v3.01. Можно посмотреть у Qualys.
🔻 The Forrester Wave™: Vulnerability Risk Management, Q3 2023. Можно посмотреть у Tenable.

Почему каждый из вендоров распространяет сейчас тот или иной отчёт наглядно видно на картинках. 😉

Адекватный анализ того, что же это было с приостановкой сертификата ФСТЭК на Dr.Web Enterprise Security Suite прочитал у Алексея Комарова

Адекватный анализ того, что же это было с приостановкой сертификата ФСТЭК на Dr.Web Enterprise Security Suite прочитал у Алексея Комарова

Адекватный анализ того, что же это было с приостановкой сертификата ФСТЭК на Dr.Web Enterprise Security Suite прочитал у Алексея Комарова. На сайте реестра российского ПО Минцифры у каждого ПО есть своя страничка. И в этой страничке отмечаются уязвимости из БДУ для этого ПО, устранённые и неустранённые. На страничке Dr.Web Enterprise Security Suite значилась неустранённой древняя уязвимость BDU:2014-00226. Там суть в том, что обновления качаются по HTTP без шифрования. Непорядок. Но вроде как это уже и пофиксили давно. Но когда приостановили действие сертификата, уязвимость на странице софта значилась неустранённой, а когда восстановили действие, то уязвимость на странице стала показываться как устранённая. Т.е. кипеш был из-за странной уязвимости 2014 года? 🧐 Похоже на то.

Мораль: если ваше ПО есть в реестре Минцифры и у вас есть сертификат ФСТЭК, мониторьте раздел "неустранённые уязвимости" и активно исправляйте или доказывайте, что уже исправили. А то могут быть проблемки.