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

Посмотрел подкаст двух Александров Герасимовых про 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), считают это очень востребованной темой. От меня: периметровые сервисы это очень конкурентная область. Со стороны клиента важно оценивать качество детектирования, хоть делать это, как правило, непросто.

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

Прожектор по ИБ, выпуск №1 (01.09.2023). Вроде в прошлый раз неплохо получилось, записали ещё один эпизод тем же составом:

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

01:13 Публичные эксплоиты для уязвимостей Juniper и WinRAR
08:34 Брешь протокола BGP может привести к длительным сбоям в работе интернета
12:45 Подозрительные изменения в британском Investigatory Powers Act 2016 (IPA)
21:13 НеУязвимость curl
27:18 Google удалила пиратские URL из личных сохранённых ссылок пользователей
34:17 Взлом национального центра готовности к инцидентам и стратегии кибербезопасности Японии
36:59 Блокировка ПО со стороны Microsoft стала бы благом?

VulnsIO добавили гибкую работу с API-токенами в веб-интерфейсе

VulnsIO добавили гибкую работу с API-токенами в веб-интерфейсе

VulnsIO добавили гибкую работу с API-токенами в веб-интерфейсе. 👍 Поправил свой пост про экспорт уязвимостей из VulnsIO и скрипт.

Выпустил новую англоязычную видяшечку

Выпустил новую англоязычную видяшечку. Так получилось, что за последний год мой англоязычный блог (а вместе с ним и ютюб канал, и подкаст) окончательно свёлся к ежемесячным обзорам Microsoft Patch Tuesday. 🤷‍♂️🤦‍♂️ А остальной контент оседал только в моих телеграмм-каналах @avleonovcom и @avleonovrus. В основном, конечно, в русскоязычном. Постараюсь эту тенденцию переломить. Теперь буду выпускать один англоязычный эпизод по итогам месяца без особого фокуса на Patch Tuesday. Так должно быть поадекватнее и повеселее. 🙂

Подумывал делать эпизоды и на русском тоже, но решил не браться, т.к. получается двойная работа. Автоматический перевод яндекс-браузером могу порекомендовать только для смеха (например, отдельностоящее "CVЕ" распознает как "CV" и переводит как "резюме"). Но планирую тащить новости из канала на обсуждение в Прожектор по ИБ. Так что русскоязычные видяшки тоже в каком-то виде будут. 🙂
___

Hello everyone! This month I decided NOT to make an episode completely dedicated to Microsoft Patch Tuesday. Instead, this episode will be an answer to the question of how my Vulnerability Management month went. A retrospection of some kind.

GitHub exploits and Vulristics
00:44 PoC in Github
02:19 Vulristics vulners-use-github-exploits-flag

VM vendors updates
04:39 Qualys First-Party Application Risk Detection and Remediation
06:18 Tenable ExposureAI
07:23 SC Awards and Rapid7

Vulnerabilities
09:04 Anglo-Saxon vulnerability lists AA23-215A
12:32 August Microsoft Patch Tuesday
14:40 WinRAR Extension Spoofing (CVE-2023-38831)
15:16 Juniper RCE (CVE-2023-36844)

📘 Blogpost
🎞 Video
🎞 Video2 (for Russia)

Довольно занимательный кейс с Integer overflow в curl (CVE-2020-19909)

Довольно занимательный кейс с Integer overflow в curl (CVE-2020-19909)

Довольно занимательный кейс с Integer overflow в curl (CVE-2020-19909). Уязвимость недавно завели на NVD с описанием:

"Уязвимость целочисленного переполнения в tool_operate.c в curl 7.65.2 из-за большого значения задержки повторной попытки."

Другой бы вендор взял, да добавил эту уязвимость куда-нибудь в бюллетень как давно исправленную. Но разрабы curl-а вступили в борьбу. Основное, что они пишут: мы не знаем кто завел эту CVE, у нас был похожий кейс на hackerone, мы его пофиксили в 7.66.0 в Сентябре 2019, но это была просто бага, а не уязвимость (явно не CVSS 9.8), CVE не заводили.

Ну и основной посыл: это наш софт, и мы должны решать уязвимость это или нет.

Согласен ли я с этим? Ну, скорее нет. Как VM-щику мне бы хотелось в NVD видеть в базе уязвимостей ВСЕ уязвимости независимо от позиции вендора. Даже, если это приведёт к какому-то количеству фолсов и публичных диспутов. Вендоры и так сдерживают заведение CVE как могут.

Для недавних критичных уязвимостей Juniper (CVE-2023-36844 и 3 других), позволяющих сделать RCE , вышло подробное техническое описание и публичный PoC

Для недавних критичных уязвимостей Juniper (CVE-2023-36844 и 3 других), позволяющих сделать RCE , вышло подробное техническое описание и публичный PoC

Для недавних критичных уязвимостей Juniper (CVE-2023-36844 и 3 других), позволяющих сделать RCE , вышло подробное техническое описание и публичный PoC.

"Мы надеемся, что это кропотливое исследование будет полезно администраторам, которым нужна дополнительная информация об уязвимостях, прежде чем принять решение о необходимости их исправления, и (если они решат это сделать), что оно также будет полезно для тех, кому необходимо проверить, были ли исправления применены."

Если вы в прошлый раз закинули информацию по этим уязвимостям своим сетевикам и они вас проигнорировали, киньте им ещё раз. 😉

По мнению автора статьи на сайте Just Security, изменения в британском Investigatory Powers Act 2016 (IPA) могут упростить использование 0day уязвимостей устройств для слежки

По мнению автора статьи на сайте Just Security, изменения в британском Investigatory Powers Act 2016 (IPA) могут упростить использование 0day уязвимостей устройств для слежки

По мнению автора статьи на сайте Just Security, изменения в британском Investigatory Powers Act 2016 (IPA) могут упростить использование 0day уязвимостей устройств для слежки.

"Производителям устройств, вероятно, также придется уведомлять правительство, прежде чем делать доступными важные обновления безопасности, которые устраняют известные уязвимости и обеспечивают безопасность устройств. Соответственно, госсекретарь (Secretary of State), получив такое предварительное уведомление, теперь может попросить операторов, например, воздержаться от исправления брешей в безопасности, чтобы позволить правительству сохранить доступ в целях слежки (surveillance)."

Пока это выглядит как спекуляция автора статьи. Может вендоров обяжут уведомлять о планируемых патчах, а может нет. Может вендоров будут просить повременить с патчами, а может нет. Но направление мысли достаточно интересное, и кажется вполне в духе времени.

Можно, например, вспомнить китайское "Положение об управлении уязвимостями безопасности сетевых продуктов" (2021), в котором вендоров обязывают оперативно сообщать об выявленных уязвимостях: "информация об уязвимостях должна быть отправлена на платформу обмена информацией об угрозах сетевой безопасности и уязвимостях Министерства промышленности и информационных технологий в течение 2 дней" (статья 7, п.2).

Так что используя зарубежные продукты нужно иметь в виду, что зарубежный вендор имеет с зарубежным государственным регулятором вполне отчётливые связи, зачастую вполне формальные и нескрываемые. Используешь зарубежное - принимай риски. Не хочешь принимать - не используй. 🤷‍♂️