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

Заметки по сегодняшнему запуску MaxPatrol VM 2.5

1 комментарий

Заметки по сегодняшнему запуску MaxPatrol VM 2.5Заметки по сегодняшнему запуску MaxPatrol VM 2.5Заметки по сегодняшнему запуску MaxPatrol VM 2.5Заметки по сегодняшнему запуску MaxPatrol VM 2.5Заметки по сегодняшнему запуску MaxPatrol VM 2.5Заметки по сегодняшнему запуску MaxPatrol VM 2.5Заметки по сегодняшнему запуску MaxPatrol VM 2.5Заметки по сегодняшнему запуску MaxPatrol VM 2.5Заметки по сегодняшнему запуску MaxPatrol VM 2.5Заметки по сегодняшнему запуску MaxPatrol VM 2.5

Заметки по сегодняшнему запуску MaxPatrol VM 2.5. MaxPatrol VM - cистема управления уязвимостями нового поколения, которая реализует полное построение VM-процесса: управление активами, детектирование, приоритизация и контроль устранения уязвимостей. Уже более 500 инсталляций и их число стремительно растёт. Главная цель MP VM - не допустить эксплуатацию уязвимости в инфраструктуре.

Чем этого добиваемся?

🔹 Полное покрытие периметра, ключевых и целевых систем.
🔹 Экспертиза Positive Technologies + кастомизация продукта ("Нельзя покрыть все потребности всех клиентов" -> "Дать возможности клиентам самим или с помощью интеграторов разрабатывать детекты") ⬅️ Имхо, про кастомизацию это тектонический сдвиг для отечественного VM-а.

Три главных нововведения:

1. Сканирование веб-приложений. Эксплуатация уязвимостей на периметре в ТОП 2 векторов проникновения по данным НКЦКИ. Для поиска уязвимостей веба раньше был нужен отдельный DAST-сканер (MP8, PT BlackBox), сейчас полноценное DAST-сканирование веб-приложений возможно делать прямо в MPVM. Функционально там тот же движок, что и в PT BlackBox.

🔩 Крутая фишка - интегрировали в MaxPatrol VM опенсурсный сканер уязвимостей Nuclei для валидации наличия уязвимостей, определенных баннерным детектом. Уязвимости, которые подтверждены нуклеем, рекомендуют исправлять в первую очередь, а остальные в плановом порядке.

Новый профиль сканирования Web Scan Optimal. Можно сканировать с аутентификацией.
Добавили новые системные дашборды: критически важные веб уязвимости на активах, Топ-20 уязвимых приложений.
Для веб-уязвимостей будут также работать политики, чтобы автоматически изменять их статус и отслеживать сроки исправления.
❗️При этом одного DAST-сканирования MaxPatrol VM недостаточно для защиты самописных веб-приложений: нужны анализаторы кода (PT AI) + Application Firewall (PT AF) + аудиты безопасности.

2. Кастомные комплаенс-проверки в HCC ("жить по своим требованиям"). Нужны если PT что-то не поддерживает или клиенты хотят сделать более расширенные проверки (сами или силами интеграторов).
Нужно подготовить 3 файла:
Файл 1 - значение параметра по умолчанию
Файл 2 - локализация требования
Файл 3 - исходный код требования

Можно экспортнуть имеющиеся требования, подредактировать и импортнуть обратно. Стандарт с требованиями можно редактировать как YAML.

3. Сканирование Docker. Раньше MaxPatrol не мог детектировать уязвимости в докер-контейнерах на Linux хостах - теперь может. Поддерживаются контейнеры на основе Ubuntu, Debian u Alpine Linux. По сути проваливаемся в контейнер и делаем те же детекты, что и на Linux хосте.

⚠️ Самое главное: никаких дополнительных лицензий не нужно! Если есть VM и HCC, просто обновляем и пользуемся!

Что ещё?

🔹 Мобильный сканер. Упростили перенос данных. Можно переносить результаты сканирования (а не активы). Задачи видны как импортированные.
🔹 Задачи на сканирование можно группировать по папкам (и запускать всю папку).
🔹 Можно ограничивать доступ к задачам на сканирование.
🔹 Технологические окна. "Запрещённое время сканирования". Задача ставится на паузу, после "просыпания" снова запустится сканирование с последнего хоста (сканирование хоста запустится заново).
🔹 Проверка транспортов и учётных записей. Можно выпустить отчёт по результатам сканирования.
🔹 У ручных задач выше приоритет, чем у запущенных по расписанию.
🔹 Теперь 20 потоков сканирования для одной задачи. Это настраивается в GUI и сбрасываться при обновлении не будет.
🔹 Топология в отдельной вкладке с возможностью переименования сетей.
🔹 Анализ топологий с компонентами связности.
🔹 Новые виджеты для HCC.
🔹 Глобальные исключения хостов из сканирования.
🔹 Новые отчёты по XLSX шаблону (можно делать свои).
🔹 Пентестовые проверки могут обновляться из облака (пакетная доставка). Раньше так доставлялись только аудитные.

Во второй части будет содержание Q&A.

Upd. Продолжение

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке

Добавить комментарий

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке. Гостями подкаста в этот раз были Сергей Алешинский и Андрей Исхаков из ПСБ (Промсвязьбанк). Т.к. я тоже 6 лет VM-ом в банке занимался, было интересно послушать. 🙂 Выписал некоторые тезисы.

1. IT стремятся занять позицию "давайте мы сейчас построим, а потом вы к нам придёте, мы вас послушаем и может быть что-то поправим". ИБ должны не допускать такого.
2. VM это прежде всего процесс взаимодействия людей. Важно уметь договариваться, в том числе на уровне руководства. Необходимость VM следует доносить грамотно, аргументированно и регулярно.
3. Доказывать необходимость исправления уязвимостей непросто, но это развивает технически и IT, и ИБ.
4. В ПСБ был выстроенный процесс обновления десктопов (АРМов), но после 22 года он усложнился. Теперь есть команда в составе RedTeam, которая проверяет обновления и новые версии западного ПО на закладки (дополнительно к проверенным обновлениям из БДУ). Также проходят проверки и собственные разработки.
5. Также применяется исправление уязвимостей путем отказа от legacy систем или внедрения компенсирующих мер (аудит сетевых подключений, максимальное урезание интеграций, обслуживание через терминальные станции).
6. Есть проблема с отсутствием бюллетеней безопасности отечественных вендоров. Отечественных вендоров СЗИ/САЗ это тоже касается.
7. Категоризация активов по сегментам, бизнесам, выделение наиболее критичных скоупов (например, DMZ).
8. Категоризация уязвимостей по автоматизированной методике оценки критичности уязвимостей ФСТЭК.
9. В идеале информацию об активах нужно забирать из супер-актуальной CMDB, которую обслуживает IT. А ИБ должна проводить поиск теневых активов в факультативном режиме. На практике вовлеченность ИБ в поиск проблем CMDB выше, в т.ч. приходится самим искать владельцев систем и обслуживающих подразделений. Периодичность рескана фиксируется в документации на IT-систему. Статус комплаенса систем будет виден на уровне CMDB. Необходимо внедрять VM в ITSM.
10. Проводится сканирование периметра извне. Необходимо следить за состоянием внешних сканеров, т.к. они зачастую добавлены в white list. Для внутренних сканеров, проводящих сканирование с аутентификацией, это ещё более критично.
11. У каждого компонента IT-систем есть утвержденный стандарт настроек. Разработка стандартов настроек выполняется внешней организацией. Проверки на соответствие реализуют сами. Конкретные требования зависят от контура, в котором находится сервер. Желательно иметь возможность перенести этот набор скриптов в VM-решение.
12. Этапы процесса Управления Соответствием: утверждение стандарта, тестирование на ограниченном скоупе, расширение скоупа и контроль соответствия. Центр IT-архитектуры утверждает единый тех. стек допустимых технологий. Его необходимо ограничивать и иметь в виде реестра а-ля CMDB. Проблема расширения стека (в глобальном смысле) это и проблема VM-вендора, который должен уметь всё.
13. При наслоении стандартов (например, ОС и СУБД) могут быть конфликты. Отхождения от стандарта должны согласовываться и журналироваться.
14. Трендовые уязвимости на периметре фиксятся оперативно без формального обоснования критичности. Согласование в рамках конфколла. Но тестирование патча на ограниченном скоупе всё равно необходимо выполнять.
15. Еженедельные отчёты: новая инфраструктура введенная в эксплуатацию, какая инфраструктура прошла проверки, какие уязвимости выявлены с приоритизацией. Отчёты также нужны для аудиторов.
16. Нужно стремиться к открытости VM-решений: полнота базы знаний детектов, обязательство поддерживать API-интеграции.

Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости

1 комментарий

Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости

Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости. Гостями подкаста в этот раз были Юрий Шкодин и Егор Подмоков из PT Expert Security Center (ESC). Для меня особенно интересный эпизод, т.к. ответ на вопрос куда именно в PT я вышел - вот конкретно к ним. 🙂 Выписал некоторые тезисы.

1. Трендовые уязвимости - уязвимости, которые эксплуатируются сейчас (на которые есть эксплоиты) или которые будут эксплуатироваться в ближайшее время. Это те уязвимости, на которые заказчики должны обратить внимание в первую очередь в своей инфраструктуре.
2. Трендовых уязвимостей не должно быть везде в инфраструктуре или только в DMZ? Дискуссионный вопрос, нужно исходить из модели рисков. Трендовая уязвимость на тестовом стенде внутри IT-инфраструктуры это не очень важная уязвимость.
3. Трендовость Уязвимости зависит от уязвимого продукта. Они могут быть очень специфичными: Church Management система, управления автомобилями и т.п. Необходимо учитывать реальные возможности по детектированию. Продукты, которые неинтересны ни нам, ни заказчикам, мы добавляем в black list, который, при необходимости, пересматриваем.
4. Исходные данные для оценки трендовости собираем из баз уязвимостей, бюллетеней безопасности вендоров, социальных сетей и мессенджеров, баз эксплоитов, публичных репозиториев кода.
5. Фолзы детектов уязвимостей, отчего они? Например, в детекте уязвимостей Windows по KB-шкам. Могут быть ошибки роботов-сборщиков данных. Может быть задержка реагирования на изменение в контенте вендора. Может быть вендор ПО предоставляет информацию об обновлениях недостаточно прозрачно.
6. Форки Open Source продуктов, которые не фиксят и не сообщают об уязвимостях исходного продукта. Призываем вендоров за этим следить. И желательно, чтобы вендоры публиковали информацию о своих уязвимостях в одном месте, идеально в БДУ ФСТЭК.
7. Сложности с детектами. Версионные детекты: уязвимость в выключенной фиче или выключенном ПО это уязвимость? Детекты с эксплуатацией: проверка не сработала, а насколько этому можно верить? Насколько правильно проверки реализованы и на основе каких эксплоитов?
8. Пользовательские детекты для софтов и уязвимостей - крутая тема. Идём в эту сторону.
9. Для отладки детектов необходимы реальные стенды с уязвимыми продуктами. Здесь вопросы с оценкой популярности софта (невозможно поддерживать всё) и нотификациями о выпуске новых версий софта. В эти темы тоже идём.
10. Доставка трендовых уязвимостей в MP VM за 12 часов. Трендовые уязвимости, как правило, начинают эксплуатировать через 24 часа (плюс это требование ФСТЭК из методики оценки критичности). Из них 12 нужно VM вендору на реализацию проверки и 12 нужны клиенту на детекты и исправление. Для более быстрой доставки идём к тому, что в базе MP VM будут все уязвимости, не только те, для которых есть детекты. Нужно будет только быстро добавлять детекты (возможно силами самих клиентов). Ассетная модель позволяет получить сработки без пересканирования по имеющимся данным.
11. BugBounty может использоваться для контроля известных уязвимостей сетевого периметра и выполнения SLA (например хантер может сдавать известные уязвимости старше 30 дней).
12. HCC PT Essentials это минимальный набор требований к конфигурациям, которые обязательно должны выполняться. Идём в сторону возможности реализовывать свои проверки.
13. Идеальный VM вендор. Прозрачность по текущим и будущим фичам (открытый roadmap). Улучшение покрытия продуктов. Самостоятельность заказчиков в плане наполнения базы знаний уязвимостей и детектов, возможность делиться этим контентом через маркетплейс. Метапродукты работающие с минимальным количеством людей. Автоматизированное исправление уязвимостей с аппрувом от IT.

Посмотрел запись онлайн-запуска MaxPatrol VM 2.0 и MaxPatrol HCC

Добавить комментарий

Посмотрел запись онлайн-запуска MaxPatrol VM 2.0 и MaxPatrol HCC. Выписал некоторые тезисы. 🙂

По уязвимостям

В рамках пилотов MaxPatrol VM в организациях находят в среднем ~30к уязвимостей, из них ~50 особо критичных и легко эксплуатируемых.

Главное согласовать SLA на исправление уязвимостей в организации. Идеально укладываться в 24 часа для особо критичных (что и ФСТЭК рекомендует).

Большой акцент на "трендовые уязвимости", которые отбирает и подсвечивает PT на основе пентестов и хитрого анализа данных.

От меня: фокус на собственную приоритизацию сейчас у всех топовых VM-вендоров. Например, Tenable VPR и Qualys TruRisk. Дело хорошее 👍

Информация о трендовых уязвимостях попадает в MaxPatrol VM с минимальной задержкой благодаря архитектурным изменениям в базе знаний. Привели пример кейса по добавлению трендовой уязвимости для софта (22:45), который в MaxPatrol VM вообще не поддерживается (VirtualBox). Если вдруг будет трендовая супер-критичная уязвимость, несмотря на отсутствие поддержки, исследователь добавит её с SLA в 12 часов.

По контролю конфигураций

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

Предлагается следующий процесс:

Этап 1.
1. Определение регламента принятых стандартов. Возможно надергать требований из CIS Benchmarks, чтобы составить свой.
2. Определение правил и задач по работе со стандартом, которые направляются IT-специалисту.
3. Проверка соответствия активов.
4. Проводим troubleshooting, возможно с видоизменением стандарта.
5. Принятие и внедрение стандарта на живую информационную систему.
Этап 2.
Работа с отчётами по нарушению требований (исправление или корректировка стандартов), разработка новых стандартов.

Сейчас в HCC доступный 17 стандартов PT Essential (44:13). Они разработаны совместно с пентестерами:

Windows Desktop
Windows Server
Microsoft SQL Server
Generic Linux
Oracle Database
VMware ESXi
VMware vCenter
Microsoft Exchange
RHEL-based Linux
HP UX
IBM AIX
Linux Kernel
Docker
Cisco IOS
Cisco IOS XE
Cisco ASA года
Cisco Nexus

Можно отслеживать коммуникацию с IT и выполнение установленных сроков в рамках политик.

Отдельного комплаенс сканирования нет, используется та же инвентаризация аудита. Проверки реализованы в виде запросов на собственном языке. Функционально можно сравнить с .audit от Tenable. Есть шансы, что в перспективе дадут делать свои проверки на нем. 😉

Из PT Essentials можно надёргать требований и составить из них свой стандарт.

Подробнее про PT Essential - Linux Kernel

В ядре Linux >30 млн. строк кода, 4000 разработчиков в год участвуют, каждый день 8000 строк меняются. Множество уязвимостей, особенно из-за ошибок доступа к памяти. Уязвимости добавляются быстрее, чем исправляются. Среднее время жизни критической уязвимости в ядре 5,5 лет. Проект Kernel Self Protection Project - "подушка безопасности" для устранения некоторых проблем как класса. Есть карта средств защиты ядра. Стандарт для ядра Linux был реализован с использованием этой карты и собственной дефенс экспертизы. Эти же требования были использованы в стандарте по настройке Linux систем от ФСТЭК. 👍

Методика ФСТЭК по оценке критичности уязвимостей

Теперь официально поддерживается в MaxPatrol VM. Про вопросы к реализации я уже раньше писал, это не silver bullet пока. Но и в таком виде работать в MaxPatrol VM проще, чем считать руками или скриптовать своё. Эта функциональность реализована в виде PDQL фильтра, такие фильтры будут доступны в общей библиотеке.

Добавили интеграцию с LAPS, чтобы избегать компрометации учёток с правами админа на многих хостах.

---

Крутой запуск! Многая лета новому поколению Compliance Management-а в MaxPatrol HCC! Буду активно отслеживать эту тему. 🙂 И не только я. Валерий Ледовской из X-cofig запустил канал по CM и тоже поделился впечатлениями от запуска HCC, зацените и подпишитесь! Взгляд со стороны прямых конкурентов это всегда любопытно. И чем больше будет авторских околоVM-ных каналов, тем лучше. 😉