Вчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. Баумана

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

Вчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. БауманаВчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. Баумана

Вчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. Баумана. Альма-матер, конечно, растёт и хорошеет. Первое, что удивило на подходе, - автомобильное движение возле Главного Здания (ГЗ) стало гораздо менее оживлённым, потому что дорогу сузили до одной полосы в каждую сторону. Переходить дорогу теперь стало безопасно, поэтому и светофоры убрали. Такую урбанистику я одобряю. 👍

Новые корпуса рядом с ГЗ поражают масштабом и архитектурой. 😮 Когда я подходил, моросил дождик. То, что площадь между корпусами закрыта навесом, было очень в тему. 😇 Новые корпуса рядом с ГЗ - это небольшая часть. Посмотрите на фотографии макета: везде, где горит свет, это всё теперь Бауманка. 😎

Само мероприятие проходило в студенческом коворкинге Т-Банка, что мне было отдельно приятно, учитывая, сколько долгих и счастливых лет я проработал в Тиньке.

Кроме меня, в качестве экспертов в мероприятии приняли участие Дмитрий Калинин и Аркадий Никифоров из Бастион. Дмитрий руководит департаментом по работе с уязвимостями информационных систем, а Аркадий руководит разработкой инструментов кибербезопасности. Вела мероприятие Олеся Томах с кафедры ИУ-10 МГТУ. В аудитории было около 25 ребят, окончивших 7-8 класс.

Мы начали с рассказа про Positive Technologies и Бастион, и о своих ролях в этих компаниях. Затем обсудили в интерактивной форме разнообразные темы из мира Информационной Безопасности:

🔹 Что такое Vulnerability Management, чем отличается CVE и CWE;
🔹 Важность своевременной установки обновлений безопасности;
🔹 Контроль сетевого периметра (на ярком примере взлома казино через аквариум 😅);
🔹 Zero-click уязвимости мобильных устройств;
🔹 Какую информацию могут собрать умные колонки, пылесосы и камеры в автомобилях.

Много времени уделили вопросу применения искусственного интеллекта в ИБ. Эта тема сейчас, безусловно, волнует всех независимо от возраста. 💯

Также поотвечали в блиц-режиме на вопросы об учёбе и работе.

Время в оживлённой беседе пролетело незаметно. Ребята на интенсиве собрались хорошие, заряженные. Надеюсь, многие из них свяжут свою жизнь с Информационной Безопасностью.

Спасибо большое организаторам за приглашение поучаствовать!

Разбор VM-ной вакансии от R-Vision "Инженер-аналитик по выявлению уязвимостей"

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

Разбор VM-ной вакансии от R-Vision Инженер-аналитик по выявлению уязвимостей

Разбор VM-ной вакансии от R-Vision "Инженер-аналитик по выявлению уязвимостей". Давненько не было у меня постов в этой рубрике. Но вот попалась вакансия в R-Vision, которая очень характерна для VM-вендоров. Я и сам на похожей позиции начинал свой путь в Vulnerability Management. 😇

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

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

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

🔻 Заниматься разработкой и формированием экспертизы (технические стандарты безопасности и информация по уязвимостям) в области информационной безопасности для продуктов компании;

И наконец, нужно написать скрипт, который будет автоматически генерировать правила детектирования уязвимостей:

🔻 Автоматизировать процессы по формированию экспертизы ИБ;

Таким продуктом при этом может быть всё, что угодно: операционные системы, базы данных, ERP-системы, сетевые устройства, разнообразный прикладной софт. Так как у клиентов, как правило, лютейший зоопарк, загрузка работой обеспечена на годы вперёд. 😉 Хотя с появлением нейроночек процесс упростился и ускорился.

Обратите внимание, что выше было про "технические стандарты безопасности". Это про харденинг. На вход аналитику подаётся стандарт по безопасному конфигурированию какого-то продукта (например, от CIS, ФСТЭК или самого вендора продукта). Задача аналитика - разработать для каждого требования автоматическую проверку конкретной инсталляции продукта на соответствие этому требованию. Пока накидываешь проверки, волей-неволей разбираешься и с безопасным конфигурированием. 👍

Все разработанные проверки будут работать в рамках конкретного решения (видимо, R-Vision VM, но возможно, что и не только), поэтому соискателю неизбежно придётся:

🔻 Взаимодействовать с продуктовыми командами с целью улучшения работы продуктов.

Какие скиллы нужны для этой работы? Ну, очевидно, что нужно уметь как-то кодить:

🔸 Знание Git, Python - ваши хорошие друзья;

Очевидно, что соискатель не должен бояться консоли и должен +- быть в курсе, что из себя представляет современная IT-инфраструктура:

🔸 Наличие навыков администрирования Windows, Linux систем;
🔹 Опыт администрирования сетевого и иного оборудования;

Чёткого ТЗ на такой позиции ждать не приходится. Придётся много копать самому, поэтому:

🔸 Способность работать самостоятельно, но и в команде.

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

🔹 Опыт проведения работ по инструментальному анализу защищенности или опыт работы с одним из сканеров безопасности (Nessus, Nexpose, Qualys, Max Patrol, OpenVas, RedCheck, nmap);
🔹 Навыки работы с режимом "Комплаенс" для оценки соответствия;

Тут не могу не поправить коллег, что MaxPatrol пишется в одно слово, и не "OpenVas", а OpenVAS. 😉

Также было бы неплохо, чтобы и про уязвимости соискатель тоже что-то знал:

🔹 Знание актуальных угроз и уязвимостей на Windows/ Linux платформах;
🔹 Опыт применения методологий по описанию, приоритизации и устранению уязвимостей (CVE, CVSS, VPR, OWASP);

Хотя, честно говоря, увидеть в списке сплошь проприетарный Tenable VPR (Vulnerability Priority Rating) было неожиданно. Интересно, что именно имеют в виду под OWASP. OWASP Top 10? 🤔 И в случае R-Vision странно, что в этом списке нет OVAL.

А в этом пункте коллеги намекнули на внутреннюю кухню:

🔹 Понимание принципов работы инструментов автоматизации (Apache Airflow);

Интересно было бы послушать, как именно они Apache Airflow используют при создании VM-ной экспертизы. 😉

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять

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

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять. Сейчас на Западе очень популярна тема Вульнпокалипсиса (Vulnpocalypse). Этот термин обозначает ситуацию, когда скорость обнаружения уязвимостей и появления эксплойтов для них начинает значительно превосходить скорость выпуска обновлений безопасности вендорами ПО и скорость установки этих обновлений их клиентами. В принципе, это уже сейчас похоже на правду: количество CVE растёт настолько быстро, что NVD отказались от анализа всех CVE. Microsoft Patch Tuesday вырос примерно со 100 исправляемых уязвимостей в месяц до 500+. Аналогично, каждый месяц обновляются рекорды по числу уязвимостей в отчётах Linux Patch Wednesday.

Причиной этого обычно называют развитие технологий искусственного интеллекта. И с этим можно отчасти согласиться: ИИ действительно значительно упростил поиск уязвимостей и разработку инструментов для их эксплуатации. Но, на мой взгляд, настоящая причина такого количества уязвимостей - не в ИИ, а в качестве ПО. Десятилетиями вендоры ПО писали ОЧЕНЬ плохой код. Их цель была одна - реализовать как можно больше фич за наименьшее время и наименьшие деньги. Если разработку можно было отдать на аутсорс в страны с максимально дешёвой рабочей силой и низкой культурой разработки - её отдавали. Если можно было взять бесплатный код, непонятно кем написанный и выложенный в открытый доступ (я про open source) - его использовали. В результате мы имеем то, что имеем: огромное количество уязвимостей в этом коде.

Раньше это было не так заметно, т.к. скорость прироста выявленных уязвимостей ограничивалась возможностями специалистов-ресёрчеров. А они в первую очередь искали уязвимости там, где за это платили. Как только это ограничение начало сниматься благодаря ИИ-сервисам, уязвимости начали массово проявляться. 😏 Есть основания полагать, что с развитием ИИ-инструментов темпы роста обнаруживаемых уязвимостей будут только расти.

С ростом количества уязвимостей растёт и количество обновлений, которые необходимо тестировать и устанавливать в инфраструктурах. Обновлений будет МНОГО, гораздо больше, чем было раньше. И выходить они будут ещё чаще. Сложившаяся ситуация - это плата за то, что вендоры софта могут писать плохой код, лепить из него продукты, а затем годами выпускать бесконечные заплатки для этих продуктов. А компании-клиенты готовы такие продукты покупать и использовать. 🤷‍♂️

При этом имеет место довольно занимательная ситуация. Покупать продукты клиенты готовы, а выполнять рекомендации вендоров ПО по устранению уязвимостей в купленных продуктах (устанавливать обновления, менять конфигурацию и применять другие меры защиты) они НЕ ГОТОВЫ. И ищут "индульгенции", чтобы этого не делать.

И находят! 🙂 Есть Vulnerability Management (Exposure Management)-вендоры, которые в своём маркетинге транслируют, что "нужно устранять только 1-3% уязвимостей". Только купите их решение, и они вам этот минимальный список уязвимостей покажут. 🔮 Это, конечно, безответственное шарлатанство, потому что супер-критичные уязвимости появляются из общего пула всех неустранённых уязвимостей. И появляются ВНЕЗАПНО! Сегодня уязвимость может не представлять особого интереса, а завтра стать супер-критичной из-за появления публичного эксплоита или обнаружения признаков эксплуатации уязвимости в реальных атаках. Если бы в компании своевременно устранили эту уязвимость по рекомендации вендора ПО, эта супер-критичная уязвимость им бы не была страшна, но, доверившись недобросовестному VM/EM-вендору, вместо планового устранения они получают ещё один "пожар", который может привести к серьёзному инциденту. Таким образом, вместо экономии ресурсов получается бесконечный забег по граблям.

Попытки заранее прогнозировать, какие уязвимости станут супер-критичными, предпринимаются, но их эффективность, мягко говоря, не впечатляет. Например, тот же EPSS частенько показывает высокую вероятность появления эксплоита там, где всё потом годами глухо, и показывает всё по нулям там, где есть и эксплоиты, и атаки. 🥴 С уязвимостями, у которых есть подробные публичные разборы, эксплоиты и контекст от исследователей прогнозирование более-менее работает. Но для большинства уязвимостей, например для тысяч уязвимостей в ядре Linux, такой информации просто нет. Поэтому и утверждать, что конкретную уязвимость можно игнорировать на основе куцего описания из NVD, абсолютно неадекватно и непрофессионально.

Я, конечно, не говорю, что приоритизировать уязвимости - это плохо. Вполне полезно показывать клиентам уязвимости, которые требуют немедленного внимания, в том числе через моделирование путей атаки. Но как только VM-вендор меняет риторику с "эти уязвимости нужно устранить в первую очередь" на "остальные уязвимости можно игнорировать" - это переход на тёмную сторону. 😈

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

У Антона Чувакина, в прошлом главного идеолога Gartner по Vulnerability Management, недавно вышел блогпост, в котором он предлагает провести мысленный эксперимент:

"Представьте, что завтра утром вы просыпаетесь, и благодаря настоящему волшебству любую уязвимость в ваших системах, приложениях и операционных системах можно устранить всего за 15 минут после выхода исправления. Мечта стала реальностью.

Теперь самое интересное - попробуйте разобраться, как это стало возможным.

Какие фундаментальные изменения должны были произойти в вашей инфраструктуре, чтобы такое 15-минутное окно стало реальностью?

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

Приведет ли это всю компанию к 15-минутному циклу установки исправлений? Скорее всего, нет, особенно если речь идет об устаревших системах. Но это даст вам четкую, практическую дорожную карту для модернизации вашей ИТ-инфраструктуры."

Ну а стратегически хотелось бы, чтобы безнаказанный выпуск дырявого ПО, предполагающий постоянный патчинг, когда-нибудь прекратился. И чтобы компании-клиенты стали использовать продукты от вендоров, которые инвестируют не только в поиск уязвимостей, но и в безопасную разработку кода по принципу secure by design. Да, такие решения стоили бы гораздо дороже. Но если продукт по факту имеет меньше уязвимостей и реже требует экстренных обновлений, его эксплуатация становится значительно проще и безопаснее. "Жаль только - жить в эту пору прекрасную. Уж не придется - ни мне, ни тебе." © 😉

Архитектура Kaspersky Vulnerability Management 1.0

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

Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0Архитектура Kaspersky Vulnerability Management 1.0

Архитектура Kaspersky Vulnerability Management 1.0. Две недели назад, 16 июля, прошёл вебинар Kaspersky, на котором представили решение Kaspersky Vulnerability Management 1.0. В этом посте хотелось бы рассмотреть первую часть вебинара, посвящённую архитектуре. Позже планирую разобрать и часть с демо, и блок ответов на вопросы.

Участники вебинара:

🔹 Мария Погребняк - отвечает за развитие бизнеса Vulnerability Management в "Лаборатории Касперского";
🔹 Максим Лызаев - presale, стоял у истоков продукта;
🔹 Дмитрий Волошин - presale, опыт в vulnerability management, в команде VM около полугода.

В декабре вышла бета-версия продукта, которую протестировали партнёры и заказчики - часть их замечаний успели учесть в первом релизе.

Начали с контекста, почему решение выпустили именно сейчас: уже пять лет как минимум треть атак идёт через уязвимости, и это стабильно первое место в рейтинге векторов атак. После 2022 года российский VM-рынок сильно изменился и пополнился новыми вендорами. Последние два года заказчики Kaspersky просили у компании собственное VM-решение.

Заявленные ключевые преимущества:

🔻 Инвентаризация и управление активами - зрелая развитая функциональность за счёт бесшовной интеграции с Kaspersky Security Center; заказчики, уже использующие KSC, отмечают простоту инвентаризационного этапа;

🔻 Несколько способов сканирования - агентный способ (считается преимуществом и более мощным методом) и сетевой скан (альтернатива там, где агент использовать невозможно или не нужно) - охват инфраструктуры с обеих сторон;

🔻 Работа с ошибками конфигураций как с уязвимостями - предустановленные профили ФСТЭК и международные бенчмарки; одна из функциональностей, давшая больше всего положительной обратной связи от партнёров и заказчиков;

🔻 Patch management - функциональность уже была в endpoint-продукте; преимущество в процессной составляющей - возможность пропатчить некоторый перечень ПО, убрав "фоновый шум".

Общая архитектура. Продукт работает в паре с KSC. Для коммерческого релиза VM 1.0 нужен KSC для Linux версии 16.3. VM устанавливается рядом - на том же сервере либо на отдельном. Сам VM (Vulnerability Management) - это несколько сервисов и собственная база данных: у KSC своя база, у VM своя. Используются агенты, подчинённые KSC. Агенты могут устанавливаться на Linux и на Windows - ограничений нет, но версия агентов также должна быть 16.3. У KSC есть веб-консоль. Чтобы добавить в неё разделы, касающиеся VM, устанавливается отдельный плагин.

Сценарий агентного сканирования. Агенты собирают информацию с конечных устройств: список установленного ПО, данные об операционной системе - и отправляют её на сервер по расписанию и по триггеру (триггером служит установка или удаление ПО на устройстве). Эта информация накапливается на сервере, где по расписанию, заданному администратором, запускается отдельная задача. Она сверяет полученные данные с базами уязвимостей и формирует результат, который отображается в консоли и отчётах. Этот сценарий можно назвать асинхронным: агенты отправляют информацию в своём темпе, а задача анализа на сервере работает по расписанию администратора. На практике это означает, что если устройство было доступно вчера, а сегодня офлайн - например, сотрудник ушёл в отпуск - и в тот же день в базах появились новые уязвимости, система всё равно найдёт их на этом устройстве, поскольку данные о нём уже сохранены на сервере. Второй вывод: запуск задачи на сервере не влияет на производительность конечных устройств. Задачу можно запускать хоть каждый час - она работает только с данными, уже имеющимися на сервере, независимо от состояния агентов. Передача списка ПО и данные об ОС занимают килобайты, поэтому нагрузка на сеть и вычислительные ресурсы минимальна и, скорее всего, останется незаметной.

Декларируемые преимущества агентного сканирования:

🔸 Если заказчик уже использует endpoint-агент "Лаборатории Касперского", это тот же агент - к нему просто добавляется функциональность управления уязвимостями. Именно поэтому внедрение простое: основной движок в инфраструктуре компании уже есть.

🔸 Агент передаёт на сервер сканирования данные о том, какие настройки на рабочей станции закрыты, какой порт закрыт или какое ПО "заблокировано". Благодаря этому в сводке уязвимостей не появляются уязвимости для "ПО, к которому нет доступа". Такие детали снижают число ложных срабатываний и делают итоговую картину более точной. Мой комментарий: Это интересный момент. По сути, продукт каким-то образом по умолчанию фильтрует детектируемые уязвимости по дополнительному набору критериев. Какие именно это критерии и насколько такое поведение корректно - нужно будет разбираться отдельно, поэтому здесь ждём подробностей. 😉

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

Читать далее →

VM-ный миф № 4: можно значительно улучшить процесс Управления Уязвимостями, если найти правильные слова для руководства

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

VM-ный миф № 4: можно значительно улучшить процесс Управления Уязвимостями, если найти правильные слова для руководства

VM-ный миф № 4: можно значительно улучшить процесс Управления Уязвимостями, если найти правильные слова для руководства. Довольно часто поступают вопросы в духе: "как аргументированно обосновать необходимость выстраивания полноценного процесса Vulnerability Management в организации, а не выборочного устранения отдельных находок сканера?" Когда от руководства при этом звучат возражения вроде "у нас были инциденты только через фишинг, а не через эксплуатацию уязвимостей", "построение процесса требует новой штатной единицы и бюджета", "безусловный патчинг создаст огромные трудозатраты" и т.д.

Нет, ну в целом можно посоветовать использовать методологию результативной кибербезопасности и вместе с руководителем определить, что именно "болит" в организации - какие недопустимые события (слив критичных данных, кража денег, остановка бизнес-процессов, для реального сектора вплоть до техногенных катастроф) могут реализовать злоумышленники на целевых активах. Суть в том, что затраты на выстраивание процесса будут несопоставимо меньше потенциальных потерь от инцидента, способного обрушить прибыль компании на 30-40%, вынудить сокращать штат или закрыться. На возражение "нас ломали только через фишинг, а не через уязвимости" можно объяснить, что попав внутрь через фишинг, злоумышленник продвигается к важным системам именно через уязвимости. Можно предложить пентест, чтобы оффенсив-специалисты показали реальность проблем на практике. Для компаний, подпадающих под требования регулятора, можно апеллировать к нормативке, требующей постоянного выявления и устранения уязвимостей.

Да-да, это всё можно пробовать транслировать! Но возымеет ли "цыганочка с выходом" перед руководством в исполнении простого VM-щика какой-то эффект? Не хочу обесценивать вербальную коммуникацию как таковую, но, положа руку на сердце, я бы особенно не рассчитывал, что вы "слова найдёте такие нежные", способные кардинально изменить ситуацию с VM-ом в организации. По моему глубокому убеждению, Vulnerability Management снизу в принципе не внедряется. Нигде и никогда. Устранение уязвимостей для бизнеса и IT-шников - крайне невыгодная тема и огромный объём дополнительной работы, которую они готовы выполнять исключительно из-под палки, по прямому указанию высшего руководства.

На то, что ТОП-менеджмент организации может чего-то там не понимать, я бы тоже не вёлся. 😏 Люди, добравшиеся до этого уровня - как правило, умные, циничные и с отличным кругозором. Во всяком случае CIO и CTO. А уж тем более ваш родной CISO. Всё они понимают: и про атаки, и про уязвимости, и про возможный ущерб. Поэтому если VM-ная тема в организации недофинансируется и фактически саботируется - значит, всех всё устраивает. 😉 На этом сознательно экономят, рассчитывая на то, что:

🔻 VM-щик из подручного материала соберёт что-то похожее на работающий процесс и будет носиться как белка-истеричка, поддерживая его и затыкая собой дыры; 🤪

🔻 в случае инцидента сам же VM-щик и станет крайним. F 🫡

Поэтому, ИМХО, если руководство организации принципиально не готово выделять ресурсы на VM и насаждать его сверху, углубляться в разъяснения нерационально. "Если надо объяснять, то не надо объяснять". © Не хотят ТОПы работающего VM-процесса - значит, его не будет. Хотят пройти через критичный киберинцидент прежде чем внедрять базовые ИБ-процессы - значит, будет так. Плетью обуха не перешибёшь. VM-щику в такой организации вместо отчаянного евангелизма лучше потратить время на что-то более полезное. Резюме обновить например. 😉 А если смена работы не вариант - как минимум осознавать положение вещей, границы своих возможностей и стараться самому не подставляться почём зря.

Июльский Microsoft Patch Tuesday

3 комментария

Июльский Microsoft Patch Tuesday

Июльский Microsoft Patch Tuesday. На второй неделе июля я был в отпуске в Санкт-Петербурге, потом навалились другие задачки, поэтому выпускаю обзор только сейчас. Но лучше поздно, чем вообще никогда. Особенно учитывая, какой в этот раз необычный MSPT. 😉 Всего 571 уязвимость, почти в 3 раза (❗️) больше, чем в июне. Есть 4 уязвимости с признаком эксплуатации в реальных атаках:

🔻 RCE - Microsoft SharePoint (CVE-2026-58644). Злоумышленник с правами не ниже владельца сайта (Site Owner) может внедрить и удаленно выполнить произвольный код на сервере SharePoint.

🔻 RCE - Microsoft SharePoint (CVE-2026-50522). Описание уязвимости аналогично CVE-2026-58644. По данным ZDI, уязвимость CVE-2026-50522 была успешно продемонстрирована на Pwn2Own Berlin. Несмотря на это, Microsoft указывает статус Exploit Maturity как "Unknown", хотя исследователи уже предоставили компании рабочий эксплойт. Это еще раз показывает, что не стоит полностью полагаться на оценки вендоров ПО и лучше самостоятельно оценивать риски. Если у вас есть серверы SharePoint, доступные из Интернет, рекомендуется как можно скорее протестировать и установить обновление, устраняющее уязвимость.

🔻 EoP - Microsoft SharePoint Server (CVE-2026-56164). Уязвимость в Microsoft Office SharePoint позволяет неаутентифицированному злоумышленнику удаленно повысить свои привилегии. Microsoft рекомендует включить интерфейс антивирусного сканирования AMSI на сервере и установить режим проверки тела запросов (Request Body Scan) в значение Full для снижения риска эксплуатации уязвимости.

🔻 EoP - Active Directory Federation Services (CVE-2026-56155). Недостаточная гранулярность управления доступом (CWE-1220) в Active Directory Federation Services (AD FS) позволяет авторизованному злоумышленнику локально повысить свои привилегии. Успешная эксплуатация этой уязвимости может позволить злоумышленнику получить права администратора.

Есть ещё 8 уязвимостей с публичным эксплоитом:

🔸 EoP - Windows User Interface Core (CVE-2026-50454). Уязвимость, связанная с обходом относительного пути (Relative Path Traversal, CWE-23) позволяет авторизованному злоумышленнику локально повысить свои привилегии. В случае успешной эксплуатации этой уязвимости злоумышленник может получить привилегии уровня SYSTEM. PoC эксплоита запускается из обычного процесса без повышенных привилегий, принадлежащего локальному администратору, и открывает интерактивную командную строку с правами NT AUTHORITY\SYSTEM.

🔸 EoP - Windows WalletService (CVE-2026-49176). Неправильное управление привилегиями (CWE-269) позволяет авторизованному злоумышленнику локально повысить свои привилегии. PoC-эксплойта запускает командную строку с правами SYSTEM.

🔸 RCE - Microsoft Message Queuing Queue Manager (CVE-2026-54992). Существующий PoC эксплоита демонстрирует отказ в обслуживании (DoS), а не выполнение кода.

🔸 EoP - Windows Narrator Braille (CVE-2026-58635). Согласно описанию Microsoft, злоумышленник, успешно проэксплуатировавший эту уязвимость, сможет выполнить произвольный код в контексте безопасности учётной записи NT AUTHORITY\Network Service. Однако в описании PoC-а эксплоита сообщается, что непривилегированный злоумышленник сможет получить права NT AUTHORITY\SYSTEM.

🔸 EoP - Windows Cloud Files Mini Filter Driver (CVE-2026-58613). Использование памяти после её освобождения (use after free, CWE-416) в драйвере Windows Cloud Files Mini Filter Driver позволяет авторизованному злоумышленнику локально повысить свои привилегии. В случае успешной эксплуатации этой уязвимости атакующий может получить привилегии SYSTEM. Подробности эксплуатации описаны в отчёте Talos Vulnerability Report TALOS-2026-2426.

🔸 InfDisc - Windows Win32k (CVE-2026-50416). Злоумышленник, успешно проэксплуатировавший эту уязвимость, потенциально может прочитать небольшие фрагменты памяти кучи (heap memory). В описании PoC-а эксплоита упоминаются вкладки Chrome, Discord, Explorer, Spotify и окна в системном трее. Но похоже перехватывать пароли с помощью этой уязвимости не получится.

🔸 InfDisc - Windows Kernel (CVE-2026-50475). Чтение данных за пределами буфера (buffer over-read, CWE-126) в ядре Windows позволяет авторизованному злоумышленнику локально раскрыть конфиденциальную информацию. Подробности эксплуатации описаны в отчёте Talos Vulnerability Report TALOS-2026-2443.

🔸 EoP - Azure Spring Apps (CVE-2026-50338). Злоумышленник, успешно проэксплуатировавший данную уязвимость, может получить повышенные привилегии. Если верить автору PoC-а эксплоита, речь идёт об уязвимости, позволяющей обойти аутентификацию между издателями (cross-issuer authentication bypass) в ресурсном сервере Spring Cloud Azure B2C.

Из остальных уязвимостей можно выделить:

🔹 RCE - Windows Remote Desktop Protocol (CVE-2026-56190). Для эксплуатации этой уязвимости не нужны авторизация и взаимодействие с пользователем. Причина проблемы - использование неинициализированного ресурса (CWE-908). Специально подготовленный RDP-трафик может вызвать ошибку, которая в некоторых случаях позволяет злоумышленнику выполнить код. RDP-серверы часто становятся целью атак, поэтому стоит проверить, какие системы доступны из Интернет, и в первую очередь обратить внимание на них.

🔹 RCE - Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central (On Premises) (CVE-2026-55944). Уязвимость можно эксплуатировать, отправив специально подготовленный запрос на вход в уязвимый сервер Dynamics NAV или Business Central. Это приводит к обработке недоверенных данных и может позволить злоумышленнику выполнить код. Для эксплуатации не требуется взаимодействие с пользователем или аутентификация.

🔹 EoP - Microsoft Windows VMSwitch (CVE-2026-57092). Это уязвимость типа use-after-free, которая позволяет злоумышленнику с низкими привилегиями получить полный контроль над хост-системой через границу виртуальной машины ("across a VM boundary"). Эксперты ZDI сообщали, что похожий эксплойт был продемонстрирован на ESXi во время Pwn2Own Berlin, однако проблема не ограничивается только ESXi. Если в ваших системах Hyper-V используется VMSwitch (что, скорее всего, так), рекомендуется как можно быстрее проверить и установить исправление.

🔹 Spoofing - Microsoft Exchange (CVE-2026-55008). Злоумышленник может отправить специально подготовленное письмо, которое выполнит JavaScript-код при открытии в OWA. Для атаки не нужны ни вложения, ни макросы - достаточно просто открыть письмо. Если в вашей организации используется OWA, лучше как можно скорее проверить и установить исправление.

🔹 RCE - Windows DHCP Server (CVE-2026-50518, CVE-2026-56159, CVE-2026-48564, CVE-2026-50370), Windows DHCP Client (CVE-2026-54128), Windows Message Queuing Service (MSMQ) (CVE-2026-50447), Windows Admin Center (WAC) (CVE-2026-56196), Windows FTP Service (CVE-2026-49172), Windows GDI+ (CVE-2026-50380), Windows Server Network driver (CVE-2026-56188), Microsoft Exchange (CVE-2026-55005), Windows Active Directory Domain Services (CVE-2026-49178), Windows Remote Desktop Client (CVE-2026-50474), Windows Remote Desktop Client (CVE-2026-54990, CVE-2026-58594), Windows TCP/IP (CVE-2026-54999), Windows Print Spooler (CVE-2026-58608), Windows Reliable Multicast Transport Driver (RMCAST) (CVE-2026-54982, CVE-2026-54995), Microsoft SQL Server (CVE-2026-54117), Microsoft Copilot (CVE-2026-48561).

🔹 SFB - Microsoft SharePoint Server (CVE-2026-55040).

🔹 EoP - Windows Server Update Service (WSUS) (CVE-2026-50444), Active Directory Certificate Services (CVE-2026-54121).

Есть и довольно курьёзная уязвимость:

🔹 RCE - Game: Age of Empires II: Definitive Edition (CVE-2026-50663). 😃 Уязвимость обхода относительных путей (Relative Path Traversal) в игре Age of Empires II: Definitive Edition позволяет неаутентифицированному злоумышленнику выполнять код по сети. Age of Empires II - это культовая стратегия в реальном времени от Microsoft, действие которой происходит в средневековую эпоху. Игроки развивают выбранные цивилизации, управляют ресурсами, исследуют технологии и командуют армиями в исторических кампаниях и многопользовательских сражениях. Definitive Edition включает улучшенную графику, обновлённое звуковое сопровождение и дополнительный контент. Если до сих пор играете в это - обязательно обновитесь. 😉

🗒 Полный отчёт Vulristics

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT

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

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT. Когда мы с коллегами готовили вопросы итогового тестирования для очередного потока курса "Управление Уязвимостями: от теории к практике", один из предложенных вопросов там формулировался примерно так:

Обнаружена критическая уязвимость в сервисе на периметре, который выполняет некоторую бизнес-функцию. Признаков эксплуатации нет. Вендор рекомендует срочно обновить ПО и применить защитные меры. По регламенту устранение уязвимости должно быть выполнено за 24 часа. Руководитель ИТ просит продлить срок до 72 часов, так как команда занята другим релизом. Какое решение будет наиболее правильным с точки зрения процесса VM?

🔹 Предложить внедрить компенсирующие меры в компромиссный срок.
🔹 Апеллировать к регламенту и требовать перенести релиз, эскалируя вопрос руководству.
🔹 Согласиться на 72 часа из-за отсутствия признаков эксплуатации.
🔹 Изучить возможность эксплуатации уязвимости, совместно с SOC срочно ограничить доступ к уязвимому сервису.

Какой ответ считается правильным в тесте, я не скажу. 😉 Но ситуация более чем типичная и на ней, как мне кажется, хорошо демонстрируется правильный VM-ный майндсет.

Когда говорят про VM, обычно подчеркивают необходимость искать компромиссы и выстраивать конструктивное взаимодействие с командами, чтобы вместе достигать общих целей. И это во многом действительно так. Специалистам по VM важно доносить до владельцев систем критичность выявленных проблем и объяснять связанные с ними риски. Однако на другой стороне (в IT и бизнесе) тоже работают компетентные люди, которые действуют в рамках собственных приоритетов. Устранение уязвимостей приоритетной задачей для них, как правило, не является. Поэтому переносы сроков устранения под разными предлогами или даже отказы от устранения уязвимостей - явление вполне обыденное. 🤷‍♂️

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

При реализации такого сценария вопрос уже может стоять не только об увольнении, но и о гораздо более серьезных последствиях. Вплоть до уголовной ответственности. Особенно если вы работаете в государственных организациях, на объектах КИИ или с системно значимыми сервисами. Прежние договоренности с вашими коллегами в этот момент в значительной степени обнулятся. Начнется судорожный поиск виноватых: кто отвечал за устранение злополучной уязвимости и кто недостаточно хорошо выполнил свою работу. И будьте уверены, что ваши коллеги из IT и бизнеса будут говорить примерно следующее:

"Вы VM-щики, вы должны были разбираться с этой уязвимостью. Мы в этом не специалисты и не обязаны в этом разбираться. Мы вообще не знали, что эту уязвимость нужно было устранять."

Попробуйте мысленно перенестись еще на один шаг вперед - представьте, что вы сидите на допросе, в весьма некомфортных условиях, вам в глаза светит лампа, и вы понимаете, что в своей работе что-то делали не так. Задайте себе вопрос: "Что помогло бы мне в этой ситуации? Что нужно было сделать, чтобы лично ко мне, VM-щику, не возникло вопросов?"

🔻 Если ваши коллеги из IT и/или бизнеса должны были устранять такого рода уязвимости, значит, должен быть документ, в котором прописано, какие типы уязвимостей они устраняют и в какие сроки. Эти сроки должны быть заранее согласованы и зафиксированы. Этой бумажной частью работы кто-то должен методично заниматься.

🔻 Если вы раньше знали об этой уязвимости (детектировали её в рамках сканов), значит, нужно было донести эту информацию до ответственного за устранение так, чтобы это было неотказуемо. Что значит неотказуемо? Не устно, не через мессенджеры и даже не через почту. По этой уязвимости должна существовать задача на устранение, назначенная на конкретного исполнителя, с указанием крайнего срока. Да, этот срок может быть сложно выдержать в реальных условиях, но формально и по руководящим документам он должен быть установлен. С вашей стороны всё, что нужно, должно было вылететь. Если срок устранения не был выдержан, нужно было показать свое деятельное участие: что вы пытались эскалировать проблему. Возможно, попытки эскалации все равно были бы безуспешными, но эти попытки необходимо фиксировать.

🔻 Если вы раньше не знали об этой уязвимости (НЕ детектировали её в рамках сканов), возникает вопрос: почему? Не занимались планомерным покрытием инфраструктуры регулярными сканами? Вместо качественных средств детектирования использовали быстрые? 😉 Аргумент "мы сканировали, но сканер нам ничего не показал" будет выглядеть в рамках разбирательства весьма слабо. Оценка качества детектирования - ваша задача.

И так далее. Эти формальные меры могут повысить шансы, что в случае неприятного инцидента простого VM-щика не сделают крайним: не посадят и не уволят с волчьим билетом.

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

Возвращаясь к описанной в вопросе ситуации, я плясал бы от оценки критичности уязвимости по методике ФСТЭК и формально требовал устранить уязвимость (обновлением или воркараундом) в установленный регулятором срок. А при отказе постарался бы это как можно лучше задокументировать на случай инцидента и теребил бы ответственных за устранение, пока работы не будут полностью выполнены, документируя все свои обращения и их ответы, желательно на бумаге и под роспись.

Так что склоняюсь скорее ко второму варианту. И там уж как пойдет. Получится пропушить устранение в нормативное время, отлично. 👍 Не получится пропушить, но инцидента в растянутый срок устранения не произойдет, тоже норм. 👌 Если злодеи все-таки успеют пробить периметр организации в растянутый срок устранения и это приведет к критичному инциденту - плохо. 😔 Но в этой ситуации будет что показать приехавшим разбираться людям в погонах и будет чем аргументировать, что VM-щик сделал все, что мог.

Дефолтный алгоритм такой: представьте, что вы на допросе по инциденту, случившемуся из-за эксплуатации уязвимости. Какие артефакты, по вашему мнению, могут помочь не присесть конкретно вам? 🙂 Обычно такой мысленный эксперимент подсказывает, чего вашему VM-ному процессу на самом деле не хватает. Те же VM-щики, которые всегда готовы на компромисс и не думают о последствиях для себя лично, имхо, рискуют оказаться в неожиданный момент кинутыми буквально всеми и с горячей картошкой в руках.