Архив за месяц: Сентябрь 2023

Ещё одно размышление после конференции R‑Vision, про таски на исправление уязвимостей

Ещё одно размышление после конференции R-Vision, про таски на исправление уязвимостей

Ещё одно размышление после конференции R‑Vision, про таски на исправление уязвимостей. На этой теме был акцент и в основном выступлении про R‑Vision VM, и в кейсе НРД. Несмотря на то, что таски могут быть предметом долгих разбирательств IT и ИБ, имхо, таски должны быть. Почему?

1. Слова (как и дашборды, доступ для IT-шников в VM-систему, нотификации в почте/мессенджерах и прочее) к делу не пришьёшь. А тут формальная задачка. С критичностью, исполнителем и датой заведения. И для аудитов есть, что показать, и в случае инцидента пригодится. 😏
2. Вполне вероятно, что в организации уже внедрены процессы оценки эффективности работы подразделений на основе анализа статусов тасков, можно и исправление уязвимостей оценивать по аналогии.
3. Руководство ФСТЭК требует заводить таски. Можно, конечно, рассуждать об обязательности этого руководства, но если можно соответствовать, то лучше соответствовать. 😉

Какие это должны быть таски?

Имхо, это должны быть атомарные таски 1 актив и 1 уязвимость. Почему так?

1. Удобно отслеживать реальный прогресс. Иначе, если сделать связь один ко многим или многие ко многим, как абсолютно справедливо заметил в своём вчерашнем докладе Олег Кусеров, это будет приводить к большому количеству частично выполненных тасков.
2. Удобно менять критичность таска в случае изменения критичности уязвимости или актива.
3. Удобно делать интеграцию с системами управления уязвимостями. По сути таск просто привязывается к статусу уязвимости на активе.

Сколько таких тасков будет? Допустим, у нас для одного Lin­ux хоста за месяц выходят 100 новых уязвимостей. Допустим, у нас 10000 Lin­ux хостов в инфраструктуре. Получается миллион тасков за месяц. 12 миллионов в год. И это только Lin­ux!

Отсюда следует:
1. Система для учёта тасков должна быть готова к таким объемам.
2. Вручную работать с такими тасками практически нереально.

Таски должны заводиться и закрываться автоматически по результатам детектирования уязвимостей.

✅ Таким образом ITшники, которые будут выполнять регулярный патчинг своих систем, возможно вообще без оглядки на продетектированные уязвимости, будут, в целом, автоматически соответствовать требованиям по исправлению уязвимостей и будут молодцы. 👍

❓А те ITшники, которые считают, что полное регулярное обновление им не подходит, смогут разбираться с каждой уязвимостью отдельно и тем способом, который сочтут нужным. Включая их ручную обработку. 🤷‍♂️ Может в процессе они скорректирую свои взгляды относительно регулярных обновлений. 😏

Что я вынес из доклада про R‑Vision VM

Что я вынес из доклада про R-Vision VM

Что я вынес из доклада про R‑Vision VM. Раньше конкурентным преимуществом R‑Vision было то, что они интегрируются со всеми сторонними решениями для детектирования уязвимостей, существующими на рынке. Но они пришли к тому, что некоторые задачи могут быть решены только на своём стеке, включающих в том числе и свой детект. С другой стороны, закрываться от других продуктов они не собираются, возможности для интеграции останутся.

В части детектов R‑Vision VM это OVAL/SCAP сканер. Пока, в рамках MVP, поддерживаются только Lin­ux дистрибутивы.

Западные:
🔹 Debian v. 7–11
🔹 RHEL v. 6–9
🔹 Ubun­tu v. 14.04–23.04
🔹 Suse SLED/SLES 11, 12, 15

Российские:
🔻 RedOS v. 7.3
🔻 AstraL­in­ux v. 17

Расчёт уязвимостей происходит на сервере.

Поддержку Win­dows собираются добавить в конце года — начале следующего.

Куда идут? "VM третьего поколения":

🔸 Активо-центричный подход
🔸 Автоматические сценарии обработки
🔸 Приоритизация с учётом ценности актива
🔸 Патч менеджмент

Сегодня в оффлайне на конференции R‑Vision

Сегодня в оффлайне на конференции R-Vision

Сегодня в оффлайне на конференции R‑Vision. Планирую поучаствовать в "Интерактивном круглом столе нa тему SIEM/VM". Подключайтесь к трансляции в 16:05. 😉

Как и планировал, посмотрел сегодня вебинар ScanFactory

Как и планировал, посмотрел сегодня вебинар ScanFactoryКак и планировал, посмотрел сегодня вебинар ScanFactoryКак и планировал, посмотрел сегодня вебинар ScanFactoryКак и планировал, посмотрел сегодня вебинар ScanFactoryКак и планировал, посмотрел сегодня вебинар ScanFactoryКак и планировал, посмотрел сегодня вебинар ScanFactoryКак и планировал, посмотрел сегодня вебинар ScanFactoryКак и планировал, посмотрел сегодня вебинар ScanFactoryКак и планировал, посмотрел сегодня вебинар ScanFactoryКак и планировал, посмотрел сегодня вебинар ScanFactory

Как и планировал, посмотрел сегодня вебинар Scan­Fac­to­ry. Выписал некоторые моменты.

1. Scan­Fac­to­ry делают не свой сканер, а агрегатор сканеров. Это сознательная стратегия. Выдают инфу 1 в 1 как выдаёт её сканер (но могут делать дополнительную ручную верификацию). Как именно запускают сканеры и делают дедупликацию — это и есть суть проекта и ноу-хау. Работают только с юрлицами для сканирования их собственных IP-адресов.
2. Одно из преимуществ — возможность on-prem установки. Тогда все данные будут храниться внутри компании, а интеграция с облаком будет производиться только для обновления сканеров. Опция для клиентов со сканированием > 2000 хостов. От меня: переход EASM-решений к разворачиванию on-prem это логичный путь к реализации black-box сканированию внутренней инфраструктуры. В Q&A про это прямо спрашивали, ответ: "Сейчас возможности сканировать внутреннюю инфраструктуру нет, но мы думаем, чтобы двигаться в этом направлении".
3. Отслеживают блокировки сканирования, например Qra­tor-ом (зачеркивают в результатах).
4. Для портов собирают скриншоты — красиво и полезно для поиска неприкрытых админок.
5. Прогнозы по угрозам сбываются. С Битриксом отдельная беда — нероссийские сканеры уязвимости в нём не находят, российских сканеров мало.
6. Находили у клиентов RCE на периметре в зарубежных продуктах: Con­flu­ence, Exchange, Fortinet (SSL VPN For­ti­Gate), Cit­rix, Ivan­ti EMM (Mobile­Iron), Juniper, vBul­letin.
7. Другие типы уязвимостей, которые находили у клиентов: пароли по умолчанию, ошибки конфигурации, забытые файлы, перехваты поддоменов.
8. Собираются расширять набор сканеров, автоматизировать техники пентестеров. Хотят добавить AI для автоматической верификации уязвимостей, генерации правил детектов, написания инструкций по исправлению. - Интересная подборка тем для применения AI
9. Находятся в процессе получения сертификата ФСТЭК.

Отдельное спасибо, что подсветили в презентации канал @avleonovrus! Было очень приятно. 😊

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

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

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

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

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Glob­al Dig­i­tal Space"

0:35 Как зашёл прошлый эпизод
2:08 Лев и Максим делятся впечатлениями от Kazan Dig­i­tal Week
7:06 На какие мероприятия по ИБ мы ходим
11:06 Приостановка сертификата ФСТЭК на Dr.Web Enter­prise Secu­ri­ty Suite
19:04 Cis­co покупает Splunk
25:59 Про RCE уязвимость BDU:2023–05857 в модулe land­ing CMS "1С-Битрикс: Управление сайтом".
30:02 Новые подробности инцидента с FDM и скрипт для детекта
32:21 Занятные моменты детектирования Lin­ux уязвимостей на примере CVE-2022–1012, RPM-based дистрибутивы и импортозамещение
44:02 Прощание от Mr. X