Поучаствовал сегодня в записи онлайн-курса по Vulnerability Management-у от Positive Technologies. В отличие от Бауманского курса, где VM это один из многих модулей, в PT-шном курсе это основная специализация. Говорят, что курс практически готов. Большую часть начитали спикеры из команды Позитива. Я же немного разнообразил "взглядом со стороны клиента": про управление активами и общение с IT (фрустрацию, челобитные, докажи-покажи). Получилось в несколько более расширенном виде, чем в постах, приблизительно минут на 30 записи.
Релиз курса планируют на 22 октября. Курс будет платным, но говорят, что цена будет небольшой, только чтобы отбить затраты на разработку/съемку. Как и подкаст по VM-у КиберДуршлаг, мне эта позитеховская тема кажется очень интересной и полезной. Когда курс выйдет, планирую его тоже пройти и поделиться впечатлениями. 🙂
9 октября Позитивы запускают новый продукт MaxPatrol EDR. Что это значит в контексте Vulnerability Management-а? То, что у PT теперь будет решение, предполагающее установку агентов на хостах. В первую очередь эти агенты будут собирать данные для отслеживания и блокировки зловредной активности. Но также напрашивается и идея использовать эти агенты для инвентаризации, чтобы детектить уязвимости и мисконфигурации. Так что будем следить за этой темой. Вполне вероятно, что до полноценного агентного сканирования в MaxPatrol VM может быть не так далеко.
Судя по фразе в лендинге "Автоматизирует обнаружение и реагирование, обеспечивает своевременную и непрерывную защиту устройств на различных операционных системах", агенты должны выпустить и под Windows, и под Linux.
1. Мне кажется целеполагание "я делаю это для людей" хоть и имеет право на существование, но не особо эффективное и устойчивое, т.к. сводит процесс самовыражения в бесконечную погоню за расширением аудитории/лайками/подписками/репостами. Сам я как-то не размышляю о том, что будет лучше восприниматься аудиторией, текст или аудио/видео. Что хочу, то и делаю. В первую очередь для себя. 🙂
2. Для меня мои телеграмм-каналы и блог это прежде всего расшаренная записная книжка. Что-то показалось интересным - записал. Если вдруг понадобилось - нашёл и как-то использовал. Частенько приходят ко мне с каким-то вопросом, а я к краткому ответу добавляю "а вот у меня посты на эту тему были". Удобненько. То, что кто-то это читает и кому-то заходит, это безусловно приятное, но побочное явление.
3. Я вообще человек необщительный. Насколько я понимаю, некоторым людям нравится собираться, тусить, общаться, публично выступать и т.д. Они от этого заряд энергии получают. Вообще не моя тема. 🙂 Я на общение энергию только трачу, а потом в условной изоляции восстанавливаюсь. Поэтому энергию на общение я стараюсь экономить. Прожектор по ИБ в этом отношении идеален для меня. Созваниваюсь в онлайне на час и обсуждаю с интересными мне людьми интересные темы. Как побочный продукт получается видяшка, которой (после минимальной редактуры) можно поделиться. Т.е. у меня, как думаю и моих собеседников, основная мотивация приятно провести время в разговоре. А если это ещё и кто-то другой вдруг послушает и ему понравится, так вообще же отлично. Милости просим на наши посиделки. 🙂
4. Насколько я могу судить со стороны, КиберДуршлаг это более амбициозная активность. В этих разговорах с гостями-VMщиками, как мне кажется, нарабатывается общая база знаний российского Vulnerability Management-а, которая может быть затем осмыслена, переработана и использована в рамках множества интересных и полезных инициатив. Такие интервью это возможность вынести пласты скрытых знаний на поверхность, что, как мне кажется, было бы гораздо сложнее сделать в оффлайновой текстовой форме, без живой дискуссии и проговаривания. Так что очень жду этого подкаста в паблике. 🙂
Насчёт медийной активности по Vulnerability Management-у, о которой вчера писал. Раз уж Михаил уже засветил её в своём канале, то тоже не буду интригу нагнетать. 🙂 Речь о новом еженедельном подкасте КиберДуршлаг от Positive Technologies. Подкаст будет целиком посвящён Vulnerability Management-у. Меня позвали туда гостем в первый выпуск. Обсудили кучу тем, начиная от обучения в ВУЗе (как обычно, попиарил курс по ТОИБАСу), заканчивая размышлениями о необходимости сертификации сканеров по функциональным возможностям и качеству детектирования уязвимостей. 🫣 Не знаю, что в итоге получится после монтажа, но процесс записи был увлекательным, час пролетел незаметно. Судя по гостям, которых вы можете на фотках видеть, другие эпизоды тоже должны быть огонь! 🔥 Собираюсь смотреть. 🍿🙂
PS: Гостям там, среди прочего, дарили ведро. Типа "не будь дуршлагом, будь ведром". Вы когда-нибудь ездили через всю Москву на общественном транспорте с оцинкованным ведром? Непередаваемые ощущения, могу вам сказать. 😁
Что нам стоит Vulnerability Management решение построить? В прошлом году у меня была серия постов о сложности создания своего VM-продукта (часть 1, часть 2, часть 3). Сегодня посмотрел выступление Михаила Козлова на недавнем IT-пикнике, которое тоже раскрывает эту тему. Михаил руководит продуктом MaxPatrol VM в Positive Technologies. И, кстати, у него тоже есть телеграмм-канал @KozTV, заходите подписывайтесь! 😉 Первая половина его выступления это подводка про уязвимости для широкой аудитории, а вторая половина, с 9:48, это срыв покровов про то как устроена разработка MaxPatrol VM, какие там есть нестандартные команды, чем ребята занимаются, как результаты их работы между собой стыкуются. Мне кажется, это должно быть интересно и для клиентов, чтобы осознавать масштаб и сложность того, что происходит под капотом MP VM, и для разработчиков VM-решений (текущих и будущих). 😉
Какие команды были упомянуты:
🔹Команда пентестеров. Их экспертиза используется для определения трендовых уязвимостей. 🔹Команда пайплайнов. Разрабатывают роботов, которые занимаются сбором информации об уязвимостях. Уже более 150 роботов работает! Тоже когда-то этим занимался для наполнения базы знаний MP8. 🙂 🔹Команда сбора инвентаризационных данных из систем (для работы сканирующего агента, модуля Аудит, модуля Пентест). Разные специализации, т.к. разные требования к реализуемым проверкам. 🔹Команда экспертов по системам. 🔹Команда ML. Определяют кандидатов на трендовые уязвимости. 🔹Команда ядра MaxPatrol VM. Отвечают за масштабирование системы.
Кстати, как видим на скрине, пока сбор данных об активах исключительно безагентный, но полноценных агентов тоже ждём. 🙏
Посмотрел запись онлайн-запуска 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-ных каналов, тем лучше. 😉
По итогам выступления на Positive Customer Day. Всё прошло вполне удачно. Спасибо большое коллегам из Positive Technologies за приглашение! Кажется это был мой первый доклад на "бумажную" тему. Хоть я, в основном, делал акценты на технические сложности при реализации методик, но всё равно. Оказалось, что у "бумажных" докладов своя специфика. Были вопросы в духе: почему регулятор написал документ так, а не иначе? Почему он что-то учёл, а что-то решил не учитывать? Зачем регулятор вообще выпустил тот или иной документ? Раньше я с таким не сталкивался и даже впал в лёгкий ступор. Можно, конечно, что-то фантазировать на эту тему, но такие вопросы явно не по адресу. 😅
В целом же, по итогам Q&A для себя сформулировал следующее:
1. В методику оценки критичности уязвимостей неплохо было бы добавить учёт использования уязвимости в реальных атаках (аналог CISA KEV) и вероятности появления эксплоита для неё (аналог EPSS) 2. В руководство по построению процесса управления уязвимостями было бы неплохо добавить: 2.1. Требования к актуальности данных об обнаруженных уязвимостях, например максимально допустимую периодичность сканирования. Не должно быть возможности сканировать раз в квартал и делать какие-то выводы на основе этого. 2.2. Требования к полноте покрытия активов. Не должно быть активов (хостов, софтов, сетевых устройств и т.д.), которые не покрываются средствами детектирования уязвимостей. Должен быть какой-то процесс подтверждения, что VM-решение умеет детектировать уязвимости для всех активов в организации. Если есть какой-то актив, для которого автоматическое детектирование уязвимостей не производится, нужно с этим что-то делать. Как минимум подсветить. 2.3. Требования к оценке качества детектирования уязвимостей. Ситуация, когда несколько средств детектирования анализируют один и тот же актив и выдают совершенно разные наборы уязвимостей ненормальная. Если так происходит, значит в каких-то решениях реализована неправильная логика и такие решения нельзя использовать в процессе управления уязвимостями ("мусор на входе - мусор на выходе"). Следует ли из этого, что должен быть процесс сертификации средств детектирования уязвимостей, такой как для PCI ASV или SCAP сканеров? Возможно.
Ещё в выступлении я, среди прочего, позволил себе предположить, что подход Positive Technologies к VM-у (который я лично всячески поддерживаю), предполагающий процесс регулярного безусловного патчинга инфраструктуры не особенно сочетается с руководством ФСТЭК по построению процесса управления уязвимостями, т.к. это руководство требует тестирования обновлений для open-source и нероссийского софта по методике ФСТЭК перед установкой. Т.е. процесс регулярного безусловного патчинга может и быть, но кажется момент с тестированием обновлений должен быть определен: тестируем/не тестируем, если тестируем, то чьими силами и в каком объёме.
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.
