DARPA запускает двухлетний конкурс AI Cyber Challenge (AIxCC) на лучшую автоматическую систему для детектирования и исправления уязвимостей в исходном коде. Участвовать в этом не советую, но формат мероприятия интересный. Возможно что-то подобное могли бы организовать в Минцифре или Сколково.
Вот так и кидайся обновлять Exchange сразу после Microsoft Patch Tuesday. Оказалось, что обновления ломают неанглоязычные инсталляции Exchange, например немецкие. 🤷♂️ На MS-ных страницах уязвимостей рекомендуют пока не обновлять такие инсталляции и применять workaround.
Rapid7 сократят 18% сотрудников. На начало года их в компании было 2600. CEO Rapid7 в письме сотрудникам пишет, что компания будет фокусироваться на MDR (Managed Detection and Response) и "build the most adoptable cloud capabilities" (что бы это ни значило). Непосредственно Vulnerability Management у них и так-то не особо развивался, а теперь видимо и вовсе зачахнет. 🤷♂️
Первые впечатления от августовского Microsoft Patch Tuesday. Пока ни о чём. 🫠
Формально наиболее критичная Denial of Service - .NET and Visual Studio (CVE-2023-38180), потому что есть признаки эксплуатации. Подробностей нет, но согласитесь, что как-то сомнительно. 🤡
Больше ничего нет с эксплоитами или признаками эксплуатации.
Есть несколько Remote Code Execution - Microsoft Exchange (CVE-2023-35368, CVE-2023-38185, CVE-2023-35388, CVE-2023-38182). 3 из них точно аутентификации требуют, по одной непонятно. Эту аутентификацию можно потенциально получить через Elevation of Privilege - Microsoft Exchange (CVE-2023-21709) - "This vulnerability allows a remote, unauthenticated attacker to log in as another user". Лучше обновиться.
Remote Code Execution - Microsoft Teams (CVE-2023-29328, CVE-2023-29330). Но в наших широтах вроде его перестали использовать.
Ещё есть пачка EoP в ядре и компонентах Windows.
Почему участники багбаунти нашли в прошлом году 65 тысяч уязвимостей, а CVE зарегистрировано за это время только 25 тысяч? Подсмотрел занимательный вопрос в канале Алексея Лукацкого.
С одной стороны, ответ вроде и очевиден. CVE-шки заводят в основном на уязвимости в продуктах, разные версии которых могут находиться в эксплуатации у пользователей. А в скоуп багбаунти попадают в основном самописные веб-приложения доступные из Интернет, так что пользователи в любой момент времени пользуются определенной версией веб-приложения. В этом случае фикс уязвимости решает проблему сразу и полностью для всех пользователей веб-приложения и пользы от CVE-идентификатора в этом случае не будет.
С другой стороны, есть мобильные приложения, которые тоже часто попадают в скоуп багбаунти. А у мобильного приложения уже есть версия и пользователи могут использовать разные версии мобильного приложения. И, получается, для мобильных приложений уже может быть смысл заводить CVE.
В принципе, ничего не мешает сделать багбаунти программу вообще для любых приложений. Например, на hackerone есть багбаунти для Chrome/Chromium. И для этих уязвимостей Google заводит CVE. Ничего не запрещает самому вендору заводить CVE под найденные в рамках багбаунти уязвимости кроме нежелания этого вендора.
И не сказать, что это требует каких-то особенных усилий со стороны вендора, т.к. сама багбаунти платформа может заводить CVE уязвимости для своих клиентов. В списке CVE Numbering Authority (CNA) есть 11 организаций типа "Bug Bounty Provider", включая Bugcrowd, HackerOne, ZDI:
"Provides CVE IDs for its customers as part of its bug bounty and vulnerability coordination platform"
В общем, уязвимостей меньше, потому что не для всех уязвимостей есть смысл заводить CVE. А для тех уязвимостей, для которых смысл есть, CVE идентификаторы не заводят, т.к. сам вендор уязвимого продукта этого не хочет. 🤷♂️ А сам исследователь хоть и может добиться заведения CVE идентификатора помимо воли вендора, но это не массовая история.
PS: хороший вопрос для собеседования VM-щиков 😉
Компания Cortel, поставщик ИТ-сервисов, проводит открытое исследование "Защита персональных данных 2023". Цель: определить как в действительности обстоят дела с ПДн и их защитой. Для этого они завели анонимный опрос на яндекс-формах.
Вопросов там немного и они по делу:
🔹 Как в вашей компании выглядит процесс защиты ПДн?
🔹 Как считаете, какова вероятность штрафа от регулятора в течение года за неисполнение ФЗ-152 в вашей организации?
🔹 Поставьте галочку, если были утечки персональных данных за 2022-2023 год. 😉
🔹 Взаимодействовали ли вы с регулятором за 2022-2023 год?
Единственное, что штраф-то штрафу рознь, надо было бы в опросе сделать поправку на размер штрафа - классические 60к или оборотный. Но так тоже норм. 🙂 Приглашаю поучаствовать в опросе, результаты исследования обещают опубликовать в канале @Cortel_cloud осенью. Подпишитесь, чтобы не пропустить и коллегам, которые за ПДн отвечают тоже перешлите. 😉
Как обучать Vulnerability Management-у? Мне предложили поучаствовать в записи онлайн-курса переподготовки по ИБ для МГТУ им. Н.Э. Баумана в части VM-а. 🎓
Аудитория: слушатели курсов по профессиональной переподготовке и студенты ИБ-шники
Дедлайн: конец августа
Фронт работ: 3 ролика по 20-25 минут
Темы:
🔹 Анализ защищённости
🔹 Управление уязвимостями
🔹 Управление обновлениями
Объем небольшой, но можно сделать первый подход к полноценному семестровому курсу.
Пока у меня задумка такая:
1. Видео по анализу защищённости хочу посвятить тому, что такое уязвимости и техническим способам детектирования уязвимостей. Простые виды веб-уязвимостей продемонстрирую на своём старом проекте уязвимого приложения. Сканирование в режиме "чёрного ящика" рассмотрим на примере cpe-детектов в nmap с Vulners плагином. Для Linux уязвимостей (включая Docker-образы) рассмотрим бюллетени безопасности и SCAP-контент. Для Windows уязвимостей рассмотрим Patch Tuesday и поговорим о KB-шках. Цель - показать как работают сканеры уязвимостей, подсвятить какие там есть проблемы и сложности.
2. Видео по управлению уязвимостями планирую построить на той идее, что управление уязвимостями это не только их детектирование, а комплексный процесс, который должен быть выстроен в организации. Оттолкнемся от руководства ФСТЭК по организации VM-процесса. Разберем способы приоритизации уязвимостей (также на примере методики ФСТЭК). Коснёмся основных метрик, за которыми следует следить: покрытие хостов в инфраструктуре VM-процессом, выполнение SLA по исправлению уязвимостей. Поговорим о Vulnerability Intelligence и о том, что делать, когда для уязвимости нет автоматизированных детектов.
3. Видео по управлению обновлениями хочу построить вокруг идеи, что уязвимостей очень много, разбираться с каждой по отдельности накладно, а выход в том, чтобы договариваться с IT-шниками о процессе регулярного безусловного обновления систем. Это позволит VM-щикам избавиться от рутины и уделять больше времени наиболее критичным трендовым уязвимостям и уязвимостям, которые простым обновлением не фиксятся. Здесь хотелось сформулировать лучшие практики по общению с IT: распространенные уловки и способы их обойти, методы эскалации, идеи по метрикам/презентациям для руководства и т.п. Здесь же коснемся требований ФСТЭК по контролю безопасности обновлений и, как следствие, необходимости скорейшего импортозамещения IT-систем.
Собираю комментарии и пожелания в посте в ВК. 😉
Это мой личный блог. Всё, что я пишу здесь - моё личное мнение, которое никак не связано с моим работодателем. Все названия продуктов, логотипы и бренды являются собственностью их владельцев. Все названия компаний, продуктов и услуг, упоминаемые здесь, упоминаются только для идентификации. Упоминание этих названий, логотипов и брендов не подразумевает их одобрения (endorsement). Вы можете свободно использовать материалы этого сайта, но было бы неплохо, если бы вы разместили ссылку на https://avleonov.ru и отправили мне сообщение об этом на me@avleonov.com или связались со мной любым другим способом.