В продолжение темы с 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

Задумался о зеркале на WordPress для контента из моего телеграмм-канала @avleonovrus

Задумался о зеркале на WordPress для контента из моего телеграмм-канала @avleonovrus

Задумался о зеркале на WordPress для контента из моего телеграмм-канала @avleonovrus. 🤔

Телеграмм меня устраивает как средство создания контента.

🔸 Тут и черновики удобно хранить, и итоговый пост собирать.
🔸 И с десктопа удобно, и с телефона.

И как средство потребления контента он тоже очень хорош.

Но есть ряд вопросов:

1. Кажется, что Телеграмм довольно скоро окончательно заблокируют. В прошлый раз с Дуровым как-то договорились, но, судя по штрафам за отказ в локализации данных, не до конца. Учитывая рост возможностей DPI, думаю эффективная блокировка телеги это дело времени. Как и наш переход на национальный мессенджер а-ля WeChat.
2. Отсутствие нормальной индексации поисковыми системами. Хочется, чтобы читатели находили тебя поиском по тексту. Сейчас контент заперт внутри ТГ канала, а люди приходят только благодаря перепостам. 🤷‍♂️
3. Отсутствие структуры. Здорово, что есть тэги. Но хочется категорий, чтобы можно было выделить проекты, сделать вложенные меню и т.п.

Занятный кейс, который вы можете показать своему 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.

Под настроение решил наиграть вам своё любимое стихотворение Николая Гумилёва - Дочь Змия

Под настроение решил наиграть вам своё любимое стихотворение Николая Гумилёва - Дочь Змия. А то давно музыкальных пауз не было. И в поддержание 4-го варианта в голосовании. 😉 Стихотворение, к слову, может быть и не Гумилёва вовсе, т.к. находится только в одном конспекте его лекций. Но хуже оно от этого, разумеется, не становится. Целый мир в 9 четверостишиях.