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

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

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

На Anti-Mal­ware вышла статья Алексея Дашкова, директора Центра продуктового менеджмента R‑Vision, "Vul­ner­a­bil­i­ty man­age­ment: как выстроить процесс управления уязвимостями правильно". R‑Vision давно занимаются VM-темой, заявляют 10 лет, но раньше эта функциональность в решениях R‑Vision не была основной, а детект уязвимостей реализовывался сторонними сканерами. В этом году они презентовали специализированный продукт R‑Vision VM с собственными детектами. Статью можно рассматривать в контексте маркетинговой активности по продвижению нового продукта. 😉 Я прочитал статью и сделал выжимку.

1. Уязвимости присутствуют почти в любой инфраструктуре, их много, эксплуатация может привести к серьёзным последствиям.
2. Западные вендоры оставляют компании в РФ без поддержки и обновлений, поэтому требуется тщательная проработка VM-процесса.
3. В большинстве случаев уязвимости вызваны ошибками программирования, настройки или проектирования.
4. Важность VM подчеркивается в СТО БР ИББС, ISO 27002:2022, CIS Crit­i­cal Secu­ri­ty Con­trols, PCI DSS, руководстве по организации VM процесса ФСТЭК и др.
5. Для небольшой компании можно детектировать уязвимости сканером, а ставить задачи IT вручную силами одного ИБшника. С увеличением количества информационных систем и расширением IT-инфраструктуры требуется VM-процесс.
6. Частые трудности VM-процесса: контроль изменений IT-инфраструктуры, приоритизация уязвимостей, учёт компенсирующих мер, обоснование необходимости исправлять уязвимости для IT, отслеживание статусов/сроков устранения уязвимостей, мониторинг процесса и генерация отчётности.
7. Цикл Управления Уязвимостями: инвентаризация, выявление, приоритизация, устранение, контроль. Рекомендуется внедрять этапы последовательно.
8. Инвентаризация. Получить информацию об активах из системы мониторинга IT-инфраструктуры или CMDB, объединить активы в группы, определить ответственных, связать с подразделениями и бизнес-процессами (и др. типами используемых "нематериальных активов"), понять критическую значимость активов.
9. Выявление. С помощью сканера уязвимостей или вручную (red team­ing). Выполнять постоянно.
10. Приоритизация. Можно использовать CVSS, алгоритм НКЦКИ (от меня: скорее нет — он для принятия решения о патчинге западного ПО), методику оценки критичности ФСТЭК. CVSS не учитывает эксплоиты (от меня: tem­po­ral учитывает, не учитывает активную эксплуатацию). Базовые варианты приоритизации (устранения): только критичные уязвимости, только уязвимости с эксплоитами, только удалённо эксплуатируемые, только на критичных активах. Можно комбинировать.
11. Устранение. Приведена схема. Ключевой аспект — взаимодействие с IT. Заключается в создании задач вручную и автоматизированно (от меня: с тасками аккуратнее). Каждая уязвимость должна проходить процесс обработки с оценкой применимости (от меня: может вырождаться в докажи-покажи). Обновления должны тестироваться. Если нельзя обновить, компенсирующие меры: переконфигурирование, ограничение использования ПО/оборудования, резервирование серверов/сет. оборудования, мониторинг эксплуатации уязвимости, СЗИ (fire­wall, антивирус).
12. Контроль. Оцениваем работу IT и вырабатываем решения по улучшению VM-процесса. Проверка через повторное сканирование или через ручную эксплуатацию. Формируйте отчётность.
13. Цель VM — выявить и устранить проблемы в защите до их превращения в угрозы для бизнеса.
14. К организации VM-процесса можно подходить по-разному, главное, чтобы уязвимости своевременно устранялись и злодеи не смогли их использовать.
15. При позиционировании R‑Vision VM делают акцент на построение полного цикла VM и возможность строить процесс "для нескольких организаций в одной системе" (для сервис-провайдеров?).

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

Кстати, про Zerologon (CVE-2020–1472)

Кстати, про Zerologon (CVE-2020-1472)

Кстати, про Zerol­o­gon (CVE-2020–1472). На днях R‑Vision выложили на Хабре подробную статью про эту уязвимость.

Уязвимость старенькая, но всё ещё актуальная, в недавний расширенный список англосаксов входит.

"Она позволяет злоумышленникам изменить пароль компьютерной учетной записи контроллера домена и получить доступ к содержимому Active Direc­to­ry.

Эксплуатация Zerol­o­gon возможна на следующих не пропатченных версиях Win­dows Serv­er: 2008 R2, 2012, 2012R2, 2016, 2019. В версии Win­dows Serv­er 2022 уязвимость уже исправлена. Для реализации атаки достаточно наличия сетевой связности с устройства, к которому имеет доступ атакующий, до уязвимого контроллера домена."

В отчёте Vul­ris­tics уязвимость абсолютно топовая. Единственное что снижает критичность это тип — EoP, но в контексте контроллера домена это, конечно, совсем другая история. 😏

Ко дню защиты детей R‑Vision запустили отдельный сайт для своего детского журнала по ИБ «Безопашка»

Ко дню защиты детей R-Vision запустили отдельный сайт для своего детского журнала по ИБ «Безопашка»

Ко дню защиты детей R‑Vision запустили отдельный сайт для своего детского журнала по ИБ «Безопашка». Там все выпуски журнала в электронном формате, включая пятый, из которого я несколько страниц про уязвимости раньше выкладывал. Также там можно подписаться, "чтобы первым узнавать о новых выпусках журнала и получать полезные материалы от Безопашки". Aware­ness для детей это крутая и важная тема. 👍

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management‑у

Разбираю ответы на мои вопросы с эфира AM Live по Vulnerability Management-у

Разбираю ответы на мои вопросы с эфира AM Live по Vul­ner­a­bil­i­ty Management‑у. Часть 3/3. Поддержка методик ФСТЭК.

Про последние три вопроса распишу вместе. Каверзность их в том, что по-хорошему на них можно ответить только "да, мы поддерживаем", либо "нет, мы не поддерживаем, потому что не хотим или не можем". В любом случае для клиента польза: либо готовая автоматизация процесса так, как это требует регулятор, либо публичная обратная связь для актуализации методик.

> 5. Что вы думаете о проекте "Руководства по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)" ФСТЭК? Ваше VM-решение позволит работать по этому процессу?

Сложно комментировать поддержку документа, который на момент эфира существовал только в проекте (но сейчас уже официально опубликован). 🙂 По факту обсуждения руководства и не было. Был только ответ Сергея Уздемира из АЛТЭКС-СОФТ (1:07:37), что есть такой документ и с ним нужно ознакомиться. В своем ответе Сергей упомянул также и методику оценки критичности уязвимостей ФСТЭК. Поэтому когда последовал следующий вопрос "насколько вы в своих решениях сейчас им [методикам] соответствуете?", то представители VM-вендоров стали отвечать про методику оценки критичности, а про руководство по управлению уязвимостями больше не вспоминали. 😉 А жаль, в руководстве есть что пообсуждать.

> 3. Ваше VM-решение позволяет проводить приоритизацию уязвимостей с использованием "Методики оценки уровня критичности уязвимостей программных, программно-аппаратных средств" ФСТЭК?

Ответ начиная с 1:10:05. Четыре вендора заявили о поддержке этой методики. Для Pos­i­tive Tech­nolo­gies Max­Pa­trol VM я смотрел текущую реализацию, для R‑Vision VM, АЛТЭКС-СОФТ Red­Check и Фродекс VulnsIO пока нет.

Основной проблемой видится то, что для приоритизации по методике ФСТЭК необходимо каким-то образом получать Tem­po­ral и Envi­ron­men­tal метрики CVSS. Теоретически это можно как-то автоматически генерировать из дополнительной информации об уязвимостях и инфраструктуре, но на практике я пока этого не видел. Так что если вам будут рассказывать про реализацию этой методики, то задавайте вопросы про CVSS. 😉

> 4. Когда ваше VM-решение рекомендует установку апдейтов западного софта, учитывается ли при этом "Методика тестирования обновлений безопасности программных, программно-аппаратных средств" ФСТЭК? Является ли тестирование обновлений по методике частью VM-процесса?

Напрямую этот вопрос не задавался, но темы проверки обновлений несколько раз касались. Причем в основном при обсуждении автопатчинга. В том смысле, что автопатчинг вещь может и хорошая, но необходимость проверки обновления западного ПО как в рамках алгоритма НКЦКИ, так и по методологии ФСТЭК никто не отменял (2:29:29). И там же была реплика "Но это же не наша зона ответственности, по идее это зона ответственности IT" (2:30:15). Это конечно же не так, потому что IT уж точно не смогут оценить безопасность патчей по сложному процессу.

Поэтому варианта 2: либо VM-вендор возьмет задачу анализа обновлений на себя, либо это так и останется проблемой на стороне клиента.

В 2:51:02 Владимир Михайлов из Фродекс/VulnsIO предложил идею проверки обновлений на стороне гипотетического консорциума VM-вендоров: "заказчик, перед тем как накатить патч, установить новую версию ПО, должен проверить его по рекомендациям ФСТЭК. Он маловероятно это сам сделает. Ни один из VM-вендоров это тоже самостоятельно не сделает. Но если мы объединимся под крышей того же БДУ ФСТЭК, мы теоретически сможем собирать базу проверенных обновлений". Причем более полном виде, чем это есть сейчас в БДУ. Очень хотелось бы, чтобы из этой идеи что-то получилось. 🙏

Часть 2

Безопашка про уязвимости и новый R‑Vision VM

Безопашка про уязвимости и новый R-Vision VM
Безопашка про уязвимости и новый R-Vision VMБезопашка про уязвимости и новый R-Vision VM

Безопашка про уязвимости и новый R‑Vision VM. Вчера на PHDays 12 взял детский журнал от R‑Vision для дочки, а там оказывается контент по нашей теме. Отличная метафора с забором и объяснение сложностей детектирования. Отсылку с кибержуликом тоже оценил. 👍😅 Предыдущие выпуски есть в электронном виде.

На стенде поговорили про новый R‑Vision VM. Релиз ждем к сентябрю. R‑Vision VM будет не только агрегатором уязвимостей от сторонних решений, в нем будут собственные детекты и они уже работают. Пока только в агентном режиме (Win­dows, Lin­ux, MacOS). К сентябрю должно появиться и активное безагентное сканирование. Звучит весьма интригующе, ждем.

Картинка "Средства Анализа Уязвимостей (САУ)" и "Средства Исправления Уязвимостей (СИУ)" в рамках проекта карты российских около-VM-ных вендоров

Картинка Средства Анализа Уязвимостей (САУ) и Средства Исправления Уязвимостей (СИУ) в рамках проекта карты российских около-VM-ных вендоров

Картинка "Средства Анализа Уязвимостей (САУ)" и "Средства Исправления Уязвимостей (СИУ)" в рамках проекта карты российских около-VM-ных вендоров.

Последние выкладываю вместе. Определяющим признаком для САУ является возможность импорта CVE/BDU из внешних источников, а для СИУ возможность исправлять уязвимости (например патчингом). Хочется надеяться, что таких решений станет больше.

Традиционный dis­claimer: Характеристику не нужно воспринимать как описание всех особенностей и возможностей продукта! Тем более не стоит сравнивать продукты между собой только на основе этой характеристики. Характеристика должна показывать почему вендор попал в категорию.

Если какого-то вендора забыл в этой категории или есть вопросы по характеристикам, пишите в личку — обсудим, добавлю/поправлю. Ну или поясню почему получилось так, а не иначе. 🙂

Предыдущие картинки
- СДУИ (Инфраструктуры)
- СДУСП (Сетевого Периметра)
- СДУП (Приложений)
- СДУК (Кода)

Средства Анализа Уязвимостей (САУ) и Средства Исправления Уязвимостей (СИУ)

Средства Анализа Уязвимостей (САУ) и Средства Исправления Уязвимостей (СИУ).

5. Средства Анализа Уязвимостей (САУ)

Позволяют анализировать и приоритизировать уязвимости для конкретной инфраструктуры. Имеется в виду не дополнительная функциональность в рамках детектирующего решения, а решение позволяющее импортировать данные об уязвимостях из сторонних источников. Анализ может включать в себя построение цепочки атаки и симуляцию атаки.

R‑Vision — R‑Vision VM. Система автоматизации процесса управления уязвимостями, включающая выявление, агрегацию, приоритизацию и контроль устранения уязвимостей. Включает функциональность по анализу уязвимостей импортированных из внешних источников.

SECURITM. Сервис управления безопасностью на базе риск-ориентированного подхода. Содержит опциональный модуль управления техническими уязвимостями, позволяющий принимать результаты работы от сканеров безопасности. Оценка уровня критичности уязвимостей может проводиться в соответствие с методикой ФСТЭК.

6. Средства Исправления Уязвимостей (СИУ)

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

Kasper­sky — Secu­ri­ty Cen­ter. Продукт для управления безопасностью IT-инфраструктуры с дополнительной функциональностью по автоматическому обновлению уязвимого ПО на Win­dows хостах.