Архивы автора: Александр Леонов

Об авторе Александр Леонов

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно и моих проектах можете прочитать здесь. Приглашаю подписаться на мой канал @avleonovrus "Управление Уязвимостями и прочее" в MAX или в Telegram. Вы можете обсудить мои посты или задать вопросы в группе ВКонтакте. And I invite all English-speaking people to another Telegram channel @avleonovcom.

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. На второй неделе июля я был в отпуске в Санкт-Петербурге, потом навалились другие задачки, поэтому выпускаю обзор только сейчас. Но лучше поздно, чем вообще никогда. Особенно учитывая, какой в этот раз необычный 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. Когда мы с коллегами готовили вопросы итогового тестирования для очередного потока курса "Управление Уязвимостями: от теории к практике", один из предложенных вопросов там формулировался примерно так:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вчера на сайте Минцифры опубликовали проект "Доктрины развития системы противодействия правонарушениям, совершаемым с использованием информационно-коммуникационных технологий" (ИКТ)

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

Вчера на сайте Минцифры опубликовали проект "Доктрины развития системы противодействия правонарушениям, совершаемым с использованием информационно-коммуникационных технологий" (ИКТ). Одна из ключевых целей Доктрины - перейти от разрозненного реагирования на отдельные инциденты к единой системе профилактики, выявления и пресечения таких правонарушений за счёт координации государства, банков, операторов связи, цифровых платформ и других участников. Для этого предлагается развивать единую антифрод-инфраструктуру, совершенствовать законодательство о цифровых доказательствах и защите персональных данных, использовать искусственный интеллект и современные механизмы цифровой идентификации, а также повышать цифровую и финансовую грамотность граждан.

Доктрину будут реализовывать в три этапа:

🔹 На I этапе (2027 - 2028 годы) планируется провести подготовительные мероприятия: разработать и принять необходимые нормативные акты, протестировать новые технологии противодействия правонарушениям с использованием ИКТ, утвердить методики оценки результатов и при необходимости скорректировать сроки, процессы и объем реализации отдельных мероприятий.

🔹 На II этапе (2029 - 2030 годы, включительно) планируется создать организационную и технологическую основу для реализации Доктрины, а также разработать и поэтапно внедрить механизмы противодействия правонарушениям с использованием ИКТ.

🔹 На III этапе (2031 - 2035 годы, включительно) планируется развивать созданные механизмы и подготовить предложения по их дальнейшему совершенствованию в системе противодействия преступлениям с использованием ИКТ.

Слово "уязвимость" в тексте доктрины упоминается два раза.

"4. Технологическое развитие и инфраструктура

В целях обеспечения внедрения передовых технологий в рамках развития системы противодействия правонарушениям, совершаемым с использованием ИКТ, реализация Доктрины предполагает решение следующих задач:

…

внедрение технологий искусственного интеллекта в сфере выявления потенциальных уязвимостей и выработке стратегии по их защите;"

Если пофантазировать, то для реализации этой задачи могут быть созданы следующие системы:

🔻 AI Red Team-платформа - автоматизированный поиск уязвимостей государственных информационных систем и цифровых сервисов путём моделирования действий злоумышленников.

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

🔻 ИИ-платформа поддержки принятия решений - формирование рекомендаций по устранению выявленных уязвимостей: изменение регламентов, требований безопасности, механизмов идентификации и обмена данными.

"В долгосрочной перспективе Доктрина формирует основы для реализации эволюционного развития принципов идентификации, в том числе предполагая:

…

использование ЦТ для построения клиентских путей, в которых возможно обеспечить снижение уязвимостей и потенциальных рисков атак;"

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

А конкретно в этом пункте по сути предлагается подход, близкий к принципу Security by Design: перепроектировать клиентские пути так, чтобы в них изначально было меньше уязвимостей и меньше необходимости передавать персональные данные. Посмотрим, как именно это реализуют на практике. 🙂

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

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

VM-ный миф № 2: скорость сканирования активов на наличие уязвимостей является критически важным параметром для VM-решений. Частенько вижу такой аргумент в маркетинге новых VM-вендоров: что, дескать, раньше сканирование больших инфраструктур превращалось в пытку, а теперь, с появлением их нового решения, всё будет супербыстро: "вжух - и готово". 🪄

У меня, глядя на такие заявления, всегда возникает вопрос: а с чего это вы вдруг такие быстрые? 🙂 Видимо по замыслу маркетологов, подобные мессаджи должны интерпретироваться потенциальными клиентами так: зрелые VM-решения на рынке и их новое VM-решение обеспечивают одинаковое качество детектирования уязвимостей (см. предыдущий миф про качество детектирования 😏), и при этом у нового VM-решения настолько лучше архитектура и настолько более оптимизированные правила детектирования, что скорость сканирования получается значительно выше. 💪🌝

Если вы всерьёз в такое верите, то, как говорят клятые англосаксы, I have a bridge to sell you. На самом деле объяснение, как правило, гораздо прозаичнее: новое VM-решение просто умеет выполнять гораздо меньше проверок на активе. 🤷‍♂️ Меньше проверок - быстрее сканирование. А на разницу в качестве получаемых результатов просто закрывают глаза. 🙈 Используя медицинскую аналогию из разбора прошлого мифа: МРТ там не делают; трубочкой послушали, "дышите - не дышите", вроде ок - давай до свидания.

Я, конечно, НЕ утверждаю, что сканирование одного актива по 10 минут - это однозначный показатель качества. Напихать sleep-ов большого ума не надо. 😏 Но если сканирование идёт слишком быстро, то это повод посмотреть, какая логика детектирования была реализована и достаточно ли этой логики для вашей конкретной инфраструктуры.

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

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

Июльский "В тренде VM": уязвимость в Microsoft Exchange Server

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

Июльский "В тренде VM": уязвимость в Microsoft Exchange Server. Представляю традиционную ежемесячную подборку трендовых уязвимостей по версии Positive Technologies. В прошлом июньском выпуске было четыре уязвимости. В этот раз только одна.

🗞 Пост на Хабре
🗒 Дайджест на сайте PT

🔻 XSS - Microsoft Exchange (CVE-2026-42897). Уязвимость позволяет злоумышленнику выполнить произвольный JavaScript-код в контексте браузера пользователя, если тот откроет вредоносное письмо в Outlook Web Access (OWA). Для уязвимости опубликован публичный эксплойт, а также зафиксированы признаки её эксплуатации в реальных атаках.

🟥 Полный список трендовых уязвимостей смотрите на портале

На прошлой неделе мы семьёй отдыхали в Санкт-Петербурге

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

На прошлой неделе мы семьёй отдыхали в Санкт-Петербурге. Погода была замечательная, очень тёплая и солнечная. Только в день приезда ближе к вечеру прошла сильная гроза, но нас не задело. Стараниями жёнушки, программа получилась не менее насыщенной, чем в прошлом году. Перечислю здесь основные активности и мои впечатления.

🔹 На обзорной экскурсии в Русском музее на меня произвела впечатление скульптура императрицы Анны Иоанновны. Со школы у меня осталось весьма смутное представление о ней и об историческом периоде, в котором она правила. Ну да, бироновщина, свадьба шутов в Ледяном доме, какие-то ещё чернушные исторические анекдоты. Но у меня как-то не отложилось, почему после умершего в юном возрасте Петра II внезапно начала править племянница Петра I, а не его дочь, например. А история там очень интересная. "Игра престолов" отдыхает. 👑 После ознакомления у меня изменилось восприятие последней русской императрицы (после которой началось засилье немцев 🤷‍♂️). Андрей Иванович Остерман - очень интересный исторический персонаж. Понравилась икона Никифора Георгиева "Коронование Богоматери" (1733). Судя по всему, запрет на изображение Бога Отца (Господа Саваофа) в виде старца выполнялся нестрого. Потому что такое изображение есть даже в храме Спаса на Крови, непосредственно над сенью, возведённой над участком булыжной мостовой и фрагментом ограды, на которую попала кровь убитого Александра II. Понравился портрет А. Д. Левицкой каким-то прерафаэлитским настроением. На известной картине Василия Поленова "Христос и грешница" моё внимание привлекла надпись на греческом на заднем плане. Почему на греческом, почему не на иврите? Оказалось, что это известный исторический артефакт. Эта надпись ("ΜΗΘΕΝΑΑΛΛΟΓΕΝΗΕΙΣΠΟ … ΘΕΙΝΘΑΝΑΤΟΝ") перед святилищем Второго храма в Иерусалиме предупреждала язычников не проходить дальше под угрозой смертной казни.

🔹 В Эрмитаже в этот раз смотрели исключительно Египетский зал. У них отличный аудиогид с полноценной экскурсией. 👍 Из экспонатов больше всего запомнилась статуя Клеопатры. Из аудиогида зацепила фраза про то, что верховный бог Птах "создал мир силой своего Слова". Приятно резонирует с "В начале было Слово, и Слово было у Бога, и Слово было Бог" (Ин. 1:1–5). 😇

🔹 Ходили в Михайловский театр на Баядерку. Классический балет об индийских страстях. Никию танцевала Анжелина Воронцова. На следующий день мы сходили на экскурсию по закулисью Михайловского. Впечатлила боковая ложа с отдельным выходом на улицу, в которой члены императорской семьи смотрели спектакли инкогнито. Сейчас её, как и царскую, сдают при условии выкупа всех билетов в ложе (~ 400к ₽). Дорого-богато-комфортно. 🙂 Интересно было послушать про постановки советского периода в Михайловском театре (тогда он назывался Малый оперный театр, МАЛЕГОТ): опера "Тихий Дон" Ивана Дзержинского, опера "Война и мир" Сергея Прокофьева, балет "Тарас Бульба" Василия Соловьева-Седого. Также сходили на экскурсию по закулисью Александринского театра. Там нам показали места в партере, куда чаще всего брал билеты Фёдор Михайлович Достоевский с супругой, и ложу, которую выкупал Александр Сергеевич Пушкин.

🔹 Кстати о Пушкине. На экскурсии в его музей-квартиру меня позабавила чернильница с арапчонком, подаренная Александру Сергеевичу Павлом Нащокиным с запиской "Посылают тебе твоего предка с чернильницами". 😅 Александру Сергеевичу шутка зашла, "за арапа" он "очень благодарил".

🔹 Два раза были в музее Фаберже в Шуваловском дворце. Первый раз на выставке братьев-художников Маковских. Больше всего мне понравилась позитивная картина Владимира Маковского "На пароходе". Во второй раз мы сходили на детскую экскурсию, посвящённую часовым механизмам: от первых нюрнбергских яиц до механизмов в яйцах Фаберже и автоматонов (заводных "роботов").

🔹 Ходили на экскурсию по выставке Василия Тропинина - крепостного художника, получившего вольную в 40 лет. Понравился его портрет Самсона Суханова - русского скульптора-камнетёса из крестьян, автора пьедестала памятника Минину и Пожарскому.

🔹 Плавали на "Метеоре" в Петергоф. Мне больше всего понравились готическая (домовая церковь семьи Николая I) в парке Александрия и изумительные розы у фонтана Нептун.

🔹 Ходили в Капеллу на концерт "От романса к джазу" в исполнении Юлии Касьян и джазового ансамбля Давида Голощёкина. Мне понравилось и романсовое отделение, и джазовое. Кому интересно, есть прошлогодняя запись.

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

🔹 В Этнографический музей попали в День этнографа. В мраморном зале рельефы, оказывается, не медные, а гипсовые, покрашенные под медь. А среди образов крестьян ВНЕЗАПНО затесался Лев Николаевич Толстой. 🙂

🔹 Посмотрели, как делают мороженое на фабрике джелато. И продегустировали, конечно. Вкусно, но когда видишь, сколько туда бухают сахара и глюкозы (декстрозы), то уже вроде и не так хочется. 😅

В общем, замечательно съездили, отдохнули, нагулялись, получили море впечатлений. Буду возвращаться в рабочий режим. 🙂