Управление Уязвимостями и прочее

Вчера в качестве приглашённого эксперта поучаствовал в работе летнего интенсива по Информационной Безопасности для школьников при МГТУ им. Баумана. Альма-матер, конечно, растёт и хорошеет. Первое, что удивило на подходе, - автомобильное движение возле Главного Здания (ГЗ) стало гораздо менее оживлённым, потому что дорогу сузили до одной полосы в каждую сторону. Переходить дорогу теперь стало безопасно, поэтому и светофоры убрали. Такую урбанистику я одобряю. 👍 Новые корпуса рядом с ГЗ поражают масштабом и архитектурой. 😮 Когда я подходил, моросил дождик. То, что площадь между корпусами закрыта навесом, было очень в тему. 😇 Новые корпуса рядом с ГЗ - это небольшая часть. Посмотрите на фотографии макета: везде, где горит свет, это всё теперь Бауманка. 😎 Само мероприятие проходило в студенческом коворкинге Т-Банка, что мне было отдельно приятно, учитывая, сколько долгих и счастливых лет я проработал в Тиньке. Кроме меня, в качестве экспертов в мероприятии приняли участие Дмитрий Калинин и Аркадий Никифоров из Бастион. Дмитрий руководит департаментом по работе с уязвимостями информационных систем, а Аркадий руководит разработкой инструментов кибербезопасности. Вела мероприятие Олеся Томах с кафедры ИУ-10 МГТУ. В аудитории было около 25 ребят, окончивших 7-8 класс. Мы начали с рассказа про Positive Technologies и Бастион, и о своих ролях в этих компаниях. Затем обсудили в интерактивной форме разнообразные темы из мира Информационной Безопасности: 🔹 Что такое Vulnerability Management, чем отличается CVE и CWE; 🔹 Важность своевременной установки обновлений безопасности; 🔹 Контроль сетевого периметра (на ярком примере взлома казино через аквариум 😅); 🔹 Zero-click уязвимости мобильных устройств; 🔹 Какую информацию могут собрать умные колонки, пылесосы и камеры в автомобилях. Много времени уделили вопросу применения искусственного интеллекта в ИБ. Эта тема сейчас, безусловно, волнует всех независимо от возраста. 💯 Также поотвечали в блиц-режиме на вопросы об учёбе и работе. Время в оживлённой беседе пролетело незаметно. Ребята на интенсиве собрались хорошие, заряженные. Надеюсь, многие из них свяжут свою жизнь с Информационной Безопасностью. Спасибо большое организаторам за приглашение поучаствовать! ➡️Ⓜ️ MAX | @avleonovrus #BMSTU #BAUMANTECH #education #kids #PositiveTechnologies #Бастион #Tbank #Tinkoff #VMprocess #CVE #CWE #AI

Разбор 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. 😉 [ Читайте полностью в посте на сайте avleonov.ru ] ➡️Ⓜ️ MAX | @avleonovrus #vacancy #RVision #RVisionVM #VMAnalyst #VulnerabilityDetection #CVE #CVSS #Hardening #Compliance #Python #Linux #Windows

Сорри, забыл ссылку на полный пост добавить. 😅 Там собственно вся суть.

VM-ный миф № 5: некоторые уязвимости инфраструктуры можно вообще не устранять. Сейчас на Западе очень популярна тема Вульнпокалипсиса (Vulnpocalypse). Этот термин обозначает ситуацию, когда скорость обнаружения уязвимостей и появления эксплойтов для них начинает значительно превосходить скорость выпуска обновлений безопасности вендорами ПО и скорость установки этих обновлений их клиентами. В принципе, это уже сейчас похоже на правду: количество CVE растёт настолько быстро, что NVD отказались от анализа всех CVE. Microsoft Patch Tuesday вырос примерно со 100 исправляемых уязвимостей в месяц до 500+. Аналогично, каждый месяц обновляются рекорды по числу уязвимостей в отчётах Linux Patch Wednesday. Причиной этого обычно называют развитие технологий искусственного интеллекта. И с этим можно отчасти согласиться: ИИ действительно значительно упростил поиск уязвимостей и разработку инструментов для их эксплуатации. Но, на мой взгляд, настоящая причина такого количества уязвимостей - не в ИИ, а в качестве ПО. Десятилетиями вендоры ПО писали ОЧЕНЬ плохой код. Их цель была одна - реализовать как можно больше фич за наименьшее время и наименьшие деньги. Если разработку можно было отдать на аутсорс в страны с максимально дешёвой рабочей силой и низкой культурой разработки - её отдавали. Если можно было взять бесплатный код, непонятно кем написанный и выложенный в открытый доступ (я про open source) - его использовали. В результате мы имеем то, что имеем: огромное количество уязвимостей в этом коде. Раньше это было не так заметно, т.к. скорость прироста выявленных уязвимостей ограничивалась возможностями специалистов-ресёрчеров. А они в первую очередь искали уязвимости там, где за это платили. Как только это ограничение начало сниматься благодаря ИИ-сервисам, уязвимости начали массово проявляться. 😏 Есть основания полагать, что с развитием ИИ-инструментов темпы роста обнаруживаемых уязвимостей будут только расти. С ростом количества уязвимостей растёт и количество обновлений, которые необходимо тестировать и устанавливать в инфраструктурах. Обновлений будет МНОГО, гораздо больше, чем было раньше. И выходить они будут ещё чаще. Сложившаяся ситуация - это плата за то, что вендоры софта могут писать плохой код, лепить из него продукты, а затем годами выпускать бесконечные заплатки для этих продуктов. А компании-клиенты готовы такие продукты покупать и использовать. 🤷‍♂️ При этом имеет место довольно занимательная ситуация. Покупать продукты клиенты готовы, а выполнять рекомендации вендоров ПО по устранению уязвимостей в купленных продуктах (устанавливать обновления, менять конфигурацию и применять другие меры защиты) они НЕ ГОТОВЫ. И ищут "индульгенции", чтобы этого не делать. И находят! 🙂 Есть Vulnerability Management (Exposure Management)-вендоры, которые в своём маркетинге транслируют, что "нужно устранять только 1-3% уязвимостей". Только купите их решение, и они вам этот минимальный список уязвимостей покажут. 🔮 Это, конечно, безответственное шарлатанство... ➡️Ⓜ️ MAX | @avleonovrus #VMmyth #VMprocess #ExposureManagement #VulnerabilityRemediation #Remediation #PatchManagement #Prioritisation #CVE #NVD #EPSS #VulnerabilityResearch #AI #SecureByDesign #Gartner #OpenSource #SoftwareQuality

Архитектура 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, устанавливается отдельный плагин. Сценарий агентного сканирования. Агенты собирают информацию с конечных устройств: список установленного ПО, данные об операционной системе - и отправляют её на сервер по расписанию и по триггеру (триггером служит установка или удаление ПО на устройстве). Эта информация накапливается на сервере, где по расписанию, заданному администратором, запускается отдельная задача. Она сверяет полученные данные с базами уязвимостей и формирует результат, который отображается в консоли и отчётах. Этот сценарий можно назвать асинхронным: агенты отправляют информацию в своём темпе, а задача анализа на сервере работает по расписанию администратора. На практике это означает, что если устройство было доступно вчера, а сегодня офлайн - например, сотрудник ушёл в отпуск - и в тот же день в базах появились новые уязвимости, система всё равно найдёт их на этом устройстве, поскольку данные о нём уже сохранены на сервере. Второй вывод: запуск задачи на сервере не влияет на производительность конечных устройств. Задачу можно запускать хоть каждый час - она работает только с данными, уже имеющимися на сервере, независимо от состояния агентов. Передача списка ПО и данные об ОС занимают килобайты, поэтому нагрузка на сеть и вычислительные ресурсы минимальна и, скорее всего, останется незаметной. [ Читайте полностью в посте на сайте avleonov.ru ] ➡️Ⓜ️ MAX | @avleonovrus #Kaspersky #KasperskyVM #PatchManagement #KSC #KICS #KATA #SIEM #NGFW #webinar #ФСТЭК #DFI #Hardening #FalsePositives #TI #VirtualPatch

VM-ный миф № 4: можно значительно улучшить процесс Управления Уязвимостями, если найти правильные слова для руководства. Довольно часто поступают вопросы в духе: "как аргументированно обосновать необходимость выстраивания полноценного процесса Vulnerability Management в организации, а не выборочного устранения отдельных находок сканера?" Когда от руководства при этом звучат возражения вроде "у нас были инциденты только через фишинг, а не через эксплуатацию уязвимостей", "построение процесса требует новой штатной единицы и бюджета", "безусловный патчинг создаст огромные трудозатраты" и т.д. Нет, ну в целом можно посоветовать использовать методологию результативной кибербезопасности и вместе с руководителем определить, что именно "болит" в организации - какие недопустимые события (слив критичных данных, кража денег, остановка бизнес-процессов, для реального сектора вплоть до техногенных катастроф) могут реализовать злоумышленники на целевых активах. Суть в том, что затраты на выстраивание процесса будут несопоставимо меньше потенциальных потерь от инцидента, способного обрушить прибыль компании на 30-40%, вынудить сокращать штат или закрыться. На возражение "нас ломали только через фишинг, а не через уязвимости" можно объяснить, что попав внутрь через фишинг, злоумышленник продвигается к важным системам именно через уязвимости. Можно предложить пентест, чтобы оффенсив-специалисты показали реальность проблем на практике. Для компаний, подпадающих под требования регулятора, можно апеллировать к нормативке, требующей постоянного выявления и устранения уязвимостей. Да-да, это всё можно пробовать транслировать! Но возымеет ли "цыганочка с выходом" перед руководством в исполнении простого VM-щика какой-то эффект? Не хочу обесценивать вербальную коммуникацию как таковую, но, положа руку на сердце, я бы особенно не рассчитывал, что вы "слова найдёте такие нежные", способные кардинально изменить ситуацию с VM-ом в организации. По моему глубокому убеждению, Vulnerability Management снизу в принципе не внедряется. Нигде и никогда. Устранение уязвимостей для бизнеса и IT-шников - крайне невыгодная тема и огромный объём дополнительной работы, которую они готовы выполнять исключительно из-под палки, по прямому указанию высшего руководства. На то, что ТОП-менеджмент организации может чего-то там не понимать, я бы тоже не вёлся. 😏 Люди, добравшиеся до этого уровня - как правило, умные, циничные и с отличным кругозором. Во всяком случае CIO и CTO. А уж тем более ваш родной CISO. Всё они понимают: и про атаки, и про уязвимости, и про возможный ущерб. Поэтому если VM-ная тема в организации недофинансируется и фактически саботируется - значит, всех всё устраивает. 😉 На этом сознательно экономят, рассчитывая на то, что: 🔻 VM-щик из подручного материала соберёт что-то похожее на работающий процесс и будет носиться как белка-истеричка, поддерживая его и затыкая собой дыры; 🤪 🔻 в случае инцидента сам же VM-щик и станет крайним. F 🫡 Поэтому, ИМХО, если руководство организации принципиально не готово выделять ресурсы на VM и насаждать его сверху, углубляться в разъяснения нерационально. "Если надо объяснять, то не надо объяснять". (c) Не хотят ТОПы работающего VM-процесса - значит, его не будет. Хотят пройти через критичный киберинцидент прежде чем внедрять базовые ИБ-процессы - значит, будет так. Плетью обуха не перешибёшь. VM-щику в такой организации вместо отчаянного евангелизма лучше потратить время на что-то более полезное. Резюме обновить например. 😉 А если смена работы не вариант - как минимум осознавать положение вещей, границы своих возможностей и стараться самому не подставляться почём зря. ➡️Ⓜ️ MAX | @avleonovrus #VMmyth #VMprocess #Communication #РезБез #CISO #CIO #CTO #Pentest

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

Июльский 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), а не выполнение кода. [ Читайте полностью в посте на сайте avleonov.ru ] 🗒 Полный отчёт Vulristics ➡️Ⓜ️ MAX | @avleonovrus #Vulristics #PatchTuesday #Microsoft #MSPT #SharePoint #Exchange #Windows #ActiveDirectory #RDP #WSUS #Dynamics365 #Azure #SharePointServer #ADFS #UICore #WalletService #MSMQ #NarratorBraille #CloudFiles #Win32k #WindowsKernel #AzureSpringApps #SpringCloudAzureB2C #DynamicsNAV #BusinessCentral #HyperV #OWA #DHCPServer #DHCPClient #WAC #FTPService #GDIPlus #NetworkDriver #ADDS #RDC #TCPIP #PrintSpooler #RMCAST #RMT #SQLServer #Copilot #WindowsUpdate #ADCS #AoE2 #AoE2DE #Chrome #Discord #Explorer #Spotify #ESXi

Интересно, а как могла произойти эта опечатка? 🤔 Microsoft вручную, что ли, заполняют описания уязвимостей, каждый раз перенабирая текст? 🙄 Хотя само слово "Vulernability" мне нравится. Что-то про возможность обучаться. 😅 Если кто-то мутит обучающий проект, связанный с уязвимостями, обратите внимание. 😉 @avleonovlive

VM-ный миф № 3: специалисты по Управлению Уязвимостями должны всегда стремиться к поиску компромисса с бизнесом и IT. Когда мы с коллегами готовили вопросы итогового тестирования для очередного потока курса "Управление Уязвимостями: от теории к практике", один из предложенных вопросов там формулировался примерно так: Обнаружена критическая уязвимость в сервисе на периметре, который выполняет некоторую бизнес-функцию. Признаков эксплуатации нет. Вендор рекомендует срочно обновить ПО и применить защитные меры. По регламенту устранение уязвимости должно быть выполнено за 24 часа. Руководитель ИТ просит продлить срок до 72 часов, так как команда занята другим релизом. Какое решение будет наиболее правильным с точки зрения процесса VM? 🔹 Предложить внедрить компенсирующие меры в компромиссный срок. 🔹 Апеллировать к регламенту и требовать перенести релиз, эскалируя вопрос руководству. 🔹 Согласиться на 72 часа из-за отсутствия признаков эксплуатации. 🔹 Изучить возможность эксплуатации уязвимости, совместно с SOC срочно ограничить доступ к уязвимому сервису. Какой ответ считается правильным в тесте, я не скажу. 😉 Но ситуация более чем типичная и на ней, как мне кажется, хорошо демонстрируется правильный VM-ный майндсет. Когда говорят про VM, обычно подчеркивают необходимость искать компромиссы и выстраивать конструктивное взаимодействие с командами, чтобы вместе достигать общих целей. И это во многом действительно так. Специалистам по VM важно доносить до владельцев систем критичность выявленных проблем и объяснять связанные с ними риски. Однако на другой стороне (в IT и бизнесе) тоже работают компетентные люди, которые действуют в рамках собственных приоритетов. Устранение уязвимостей приоритетной задачей для них, как правило, не является. Поэтому переносы сроков устранения под разными предлогами или даже отказы от устранения уязвимостей - явление вполне обыденное. 🤷‍♂️ Поэтому, чтобы понять, что делать в такой ситуации, я бы рекомендовал следующее простое мысленное упражнение. Представьте наихудший сценарий: уязвимость не устранили, злоумышленники её проэксплуатировали, получили доступ к инфраструктуре, нашли другие уязвимости, проэксплуатировали и их, полностью скомпрометировали инфраструктуру компании. Деньги похищены, инфраструктура выведена из строя, бизнес остановлен (добавьте самостоятельно недопустимые события, релевантные для вашей организации). При реализации такого сценария вопрос уже может стоять не только об увольнении, но и о гораздо более серьезных последствиях. Вплоть до уголовной ответственности. Особенно если вы работаете в государственных организациях, на объектах КИИ или с системно значимыми сервисами. Прежние договоренности с вашими коллегами в этот момент в значительной степени обнулятся. Начнется судорожный поиск виноватых: кто отвечал за устранение злополучной уязвимости и кто недостаточно хорошо выполнил свою работу. И будьте уверены, что ваши коллеги из IT и бизнеса будут говорить примерно следующее: "Вы VM-щики, вы должны были разбираться с этой уязвимостью. Мы вообще об этом не знали. Мы в этом не специалисты и не обязаны в этом разбираться. Мы вообще не знали, что эту уязвимость нужно было устранять." Попробуйте мысленно перенестись еще на один шаг вперед - представьте, что вы сидите на допросе, в весьма некомфортных условиях, вам в глаза светит лампа, и вы понимаете, что в своей работе что-то делали не так. Задайте себе вопрос: "Что помогло бы мне в этой ситуации? Что нужно было сделать, чтобы лично ко мне, VM-щику, не возникло вопросов?" ➡️Ⓜ️ MAX | @avleonovrus #VMmyth #VMprocess #Remediation #VulnerabilityRemediation #CyberRisk #PatchManagement #CISO #SOC #ФСТЭК #КИИ #Documentation #exploitability #Perimeter

Вчера на сайте Минцифры опубликовали проект "Доктрины развития системы противодействия правонарушениям, совершаемым с использованием информационно-коммуникационных технологий" (ИКТ). Одна из ключевых целей Доктрины - перейти от разрозненного реагирования на отдельные инциденты к единой системе профилактики, выявления и пресечения таких правонарушений за счёт координации государства, банков, операторов связи, цифровых платформ и других участников. Для этого предлагается развивать единую антифрод-инфраструктуру, совершенствовать законодательство о цифровых доказательствах и защите персональных данных, использовать искусственный интеллект и современные механизмы цифровой идентификации, а также повышать цифровую и финансовую грамотность граждан. Доктрину будут реализовывать в три этапа: 🔹 На I этапе (2027 - 2028 годы) планируется провести подготовительные мероприятия: разработать и принять необходимые нормативные акты, протестировать новые технологии противодействия правонарушениям с использованием ИКТ, утвердить методики оценки результатов и при необходимости скорректировать сроки, процессы и объем реализации отдельных мероприятий. 🔹 На II этапе (2029 - 2030 годы, включительно) планируется создать организационную и технологическую основу для реализации Доктрины, а также разработать и поэтапно внедрить механизмы противодействия правонарушениям с использованием ИКТ. 🔹 На III этапе (2031 - 2035 годы, включительно) планируется развивать созданные механизмы и подготовить предложения по их дальнейшему совершенствованию в системе противодействия преступлениям с использованием ИКТ. Слово "уязвимость" в тексте доктрины упоминается два раза. "4. Технологическое развитие и инфраструктура В целях обеспечения внедрения передовых технологий в рамках развития системы противодействия правонарушениям, совершаемым с использованием ИКТ, реализация Доктрины предполагает решение следующих задач: ... внедрение технологий искусственного интеллекта в сфере выявления потенциальных уязвимостей и выработке стратегии по их защите;" Если пофантазировать, то для реализации этой задачи могут быть созданы следующие системы: 🔻 AI Red Team-платформа - автоматизированный поиск уязвимостей государственных информационных систем и цифровых сервисов путём моделирования действий злоумышленников. 🔻 Система анализа архитектурных и процессных уязвимостей - выявление слабых мест в государственных сервисах, межведомственном взаимодействии и бизнес-процессах, которые могут быть использованы для совершения правонарушений. 🔻 ИИ-платформа поддержки принятия решений - формирование рекомендаций по устранению выявленных уязвимостей: изменение регламентов, требований безопасности, механизмов идентификации и обмена данными. "В долгосрочной перспективе Доктрина формирует основы для реализации эволюционного развития принципов идентификации, в том числе предполагая: ... использование ЦТ для построения клиентских путей, в которых возможно обеспечить снижение уязвимостей и потенциальных рисков атак;" В этом разделе речь идёт о развитии подходов к защите цифровой личности на основе криптографического "цифрового токена" (ЦТ). Под ЦТ "понимается криптографический объект, являющийся верифицируемым цифровым отпечатком совокупности данных о физическом лице, распределенных между участниками экосистемы цифровой экономики, и служащий инструментом координации мер по защите цифровой личности". [ Читайте полностью в посте на сайте avleonov.ru ] ➡️Ⓜ️ MAX | @avleonovrus #Минцифры #AntiFraud #AI #ZeroTrust #ПДн

VM-ный миф № 2: скорость сканирования активов на наличие уязвимостей является критически важным параметром для VM-решений. Частенько вижу такой аргумент в маркетинге новых VM-вендоров: что, дескать, раньше сканирование больших инфраструктур превращалось в пытку, а теперь, с появлением их нового решения, всё будет супербыстро: "вжух - и готово". 🪄 У меня, глядя на такие заявления, всегда возникает вопрос: а с чего это вы вдруг такие быстрые? 🙂 Видимо по замыслу маркетологов, подобные мессаджи должны интерпретироваться потенциальными клиентами так: зрелые VM-решения на рынке и их новое VM-решение обеспечивают одинаковое качество детектирования уязвимостей (см. предыдущий миф про качество детектирования 😏), и при этом у нового VM-решения настолько лучше архитектура и настолько более оптимизированные правила детектирования, что скорость сканирования получается значительно выше. 💪🌝 Если вы всерьёз в такое верите, то, как говорят клятые англосаксы, I have a bridge to sell you. На самом деле объяснение, как правило, гораздо прозаичнее: новое VM-решение просто умеет выполнять гораздо меньше проверок на активе. 🤷‍♂️ Меньше проверок - быстрее сканирование. А на разницу в качестве получаемых результатов просто закрывают глаза. 🙈 Используя медицинскую аналогию из разбора прошлого мифа: МРТ там не делают; трубочкой послушали, "дышите - не дышите", вроде ок - давай до свидания. Я, конечно, НЕ утверждаю, что сканирование одного актива по 10 минут - это однозначный показатель качества. Напихать sleep-ов большого ума не надо. 😏 Но если сканирование идёт слишком быстро, то это повод посмотреть, какая логика детектирования была реализована и достаточно ли этой логики для вашей конкретной инфраструктуры. Если посмотреть на западные тренды развития Vulnerability Management, то там всё движется не к сокращению времени сканирования, а наоборот - к более глубоким проверкам без жёстких ограничений по времени. Цель - обнаружить максимум установленного ПО, модулей и библиотек независимо от того, где и как они установлены. А затем найти максимум уязвимостей в них. Чтобы это стало возможным, нужно уходить от детектирования в рамках ограниченных по времени сканов к работающим в фоне агентам, которые передают результаты по мере готовности. Такое непрерывное глубокое сканирование идёт столько, сколько требуется для получения наиболее полных и качественных результатов детектирования уязвимостей. Потому что если результаты детектирования неполные и некачественные, какой смысл в процессе Управления Уязвимостями? Что-то где-то нашли, что-то где-то устранили - сойдёт и так? 🙃 Ну а на активах, на которые невозможно установить агента, остаётся проводить сетевое сканирование (с аутентификацией и без). Но для того чтобы оно выполнялось в адекватное время, не нужно пытаться охватить одной сканирующей нодой всю инфраструктуру. Поставьте их несколько (в соответствии с рекомендациями VM-вендора), выполняйте задачи на сканирование параллельно и всё будет ок. ➡️Ⓜ️ MAX | @avleonovrus #Detection #VMprocess #VMmyth #VulnerabilityScanning #VulnerabilityDetection #NetworkScanning

Июльский "В тренде VM": уязвимость в Microsoft Exchange Server. Представляю традиционную ежемесячную подборку трендовых уязвимостей по версии Positive Technologies. В прошлом июньском выпуске было четыре уязвимости. В этот раз только одна. 🗞 Пост на Хабре 🗒 Дайджест на сайте PT 🔻 XSS - Microsoft Exchange (CVE-2026-42897). Уязвимость позволяет злоумышленнику выполнить произвольный JavaScript-код в контексте браузера пользователя, если тот откроет вредоносное письмо в Outlook Web Access (OWA). Для уязвимости опубликован публичный эксплойт, а также зафиксированы признаки её эксплуатации в реальных атаках. 🟥 Полный список трендовых уязвимостей смотрите на портале ➡️Ⓜ️ MAX | @avleonovrus #PositiveTechnologies #TrendVulns #втрендеVM #Microsoft #Exchange #Outlook #OWA #XSS #Spoofing #JavaScript #InternetExplorer #Edge #CISA #CISAKEV #KEV #exploit #GitHub #EM #EOMT #ESU

На прошлой неделе мы семьёй отдыхали в Санкт-Петербурге. Погода была замечательная, очень тёплая и солнечная. Только в день приезда ближе к вечеру прошла сильная гроза, но нас не задело. Стараниями жёнушки, программа получилась не менее насыщенной, чем в прошлом году. Перечислю здесь основные активности и мои впечатления. 🔹 На обзорной экскурсии в Русском музее на меня произвела впечатление скульптура императрицы Анны Иоанновны. Со школы у меня осталось весьма смутное представление о ней и об историческом периоде, в котором она правила. Ну да, бироновщина, свадьба шутов в Ледяном доме, какие-то ещё чернушные исторические анекдоты. Но у меня как-то не отложилось, почему после умершего в юном возрасте Петра II внезапно начала править племянница Петра I, а не его дочь, например. А история там очень интересная. "Игра престолов" отдыхает. 👑 После ознакомления у меня изменилось восприятие последней русской императрицы (после которой началось засилье немцев 🤷‍♂️). Андрей Иванович Остерман - очень интересный исторический персонаж. Понравилась икона Никифора Георгиева "Коронование Богоматери" (1733). Судя по всему, запрет на изображение Бога Отца (Господа Саваофа) в виде старца выполнялся нестрого. Потому что такое изображение есть даже в храме Спаса на Крови, непосредственно над сенью, возведённой над участком булыжной мостовой и фрагментом ограды, на которую попала кровь убитого Александра II. Понравился портрет А. Д. Левицкой каким-то прерафаэлитским настроением. На известной картине Василия Поленова "Христос и грешница" моё внимание привлекла надпись на греческом на заднем плане. Почему на греческом, почему не на иврите? Оказалось, что это известный исторический артефакт. Эта надпись ("ΜΗΘΕΝΑΑΛΛΟΓΕΝΗΕΙΣΠΟ ... ΘΕΙΝΘΑΝΑΤΟΝ") перед святилищем Второго храма в Иерусалиме предупреждала язычников не проходить дальше под угрозой смертной казни. 🔹 В Эрмитаже в этот раз смотрели исключительно Египетский зал. У них отличный аудиогид с полноценной экскурсией. 👍 Из экспонатов больше всего запомнилась статуя Клеопатры. Из аудиогида зацепила фраза про то, что верховный бог Птах "создал мир силой своего Слова". Приятно резонирует с "В начале было Слово, и Слово было у Бога, и Слово было Бог" (Ин. 1:1–5). 😇 🔹 Ходили в Михайловский театр на Баядерку. Классический балет об индийских страстях. Никию танцевала Анжелина Воронцова. На следующий день мы сходили на экскурсию по закулисью Михайловского. Впечатлила боковая ложа с отдельным выходом на улицу, в которой члены императорской семьи смотрели спектакли инкогнито. Сейчас её, как и царскую, сдают при условии выкупа всех билетов в ложе (~ 400к ₽). Дорого-богато-комфортно. 🙂 Интересно было послушать про постановки советского периода в Михайловском театре (тогда он назывался Малый оперный театр, МАЛЕГОТ): опера "Тихий Дон" Ивана Дзержинского, опера "Война и мир" Сергея Прокофьева, балет "Тарас Бульба" Василия Соловьева-Седого. Также сходили на экскурсию по закулисью Александринского театра. Там нам показали места в партере, куда чаще всего брал билеты Фёдор Михайлович Достоевский с супругой, и ложу, которую выкупал Александр Сергеевич Пушкин. 🔹 Кстати о Пушкине. На экскурсии в его музей-квартиру меня позабавила чернильница с арапчонком, подаренная Александру Сергеевичу Павлом Нащокиным с запиской "Посылают тебе твоего предка с чернильницами". 😅 Александру Сергеевичу шутка зашла, "за арапа" он "очень благодарил". 🔹 Два раза были в музее Фаберже в Шуваловском дворце. Первый раз на выставке братьев-художников Маковских. Больше всего мне понравилась позитивная картина Владимира Маковского "На пароходе". Во второй раз мы сходили на детскую экскурсию, посвящённую часовым механизмам: от первых нюрнбергских яиц до механизмов в яйцах Фаберже и автоматонов (заводных "роботов"). [ Читайте полностью в посте на сайте avleonov.ru ] ➡️Ⓜ️ MAX | @avleonovrus #Offtopic #spb #travel #дыбр #родительство

Напишу пару слов по поводу удаления национального мессенджера MAX и других приложений VK из Google Play. У меня с 2024 года Android-смартфон, на котором я принципиально не входил в аккаунт Google. Соответственно и Google Play, который без входа в аккаунт не работает, я НЕ использую. 🙂 Могу ответственно сказать: без Google Play жить вполне можно. Практически все нужные мне приложения есть в RuStore и F-Droid (оттуда я Termux беру). На крайний случай есть встроенный магазин Xiaomi GetApps. Так что сейчас удаление приложений из Google Play никак на мне не сказывается. Чего нельзя сказать об ограничениях, которые Google начнут внедрять с сентября. По этой теме ждём блокировки отечественных приложений в Android, которые будет весьма сложно обходить. 🤷‍♂️ То, что приложения VK выпилили из сторов, - конечно, весьма печально. Хоть это и было предсказуемо. С другой стороны, возможно лишившись доступа к значительной доле пользователей западных мобильных устройств, руководство VK займёт более активную позицию в направлении создания и внедрения Национальной Мобильной ОС. 🙏 Сейчас VK, по идее, становятся одними из главных интересантов в этом. ➡️Ⓜ️ MAX | @avleonovrus #Google #GooglePlay #Android #VK #MAXmessenger #НМОС

VM-ный миф № 1: качество детектирования уязвимостей у всех САЗ (Средств Анализа Защищённости) одинаковое. Хочу сделать мини-серию постов о популярных заблуждениях относительно Vulnerability Management-решений и процессов. И начну с самого вредного, на мой взгляд. Что детектирование уязвимостей - это что-то не особенно сложное, и практически любой IT/ИБ-вендор может вкатиться в область VM и быстро выпустить решения с тем же качеством детектирования уязвимостей, что и у лидеров рынка. По моему мнению, это обусловлено самой природой средств детектирования (в широком смысле). Такое средство получает доступ к некоторым активам для анализа, делает НЕЧТО, в результате чего клиент получает отчёт с обнаруженными проблемами. Как именно это НЕЧТО реализуется, по большому счёту остаётся за кадром. Это может быть какая-то примитивная логика, дающая результаты со множеством false positive и false negative-ошибок. А может быть чрезвычайно сложная логика, на реализацию, тестирование и поддержание которой тратятся внушительные ресурсы вендора. Приведу аналогию из области медицины. Чтобы выявлять аномалии в лёгких человека, можно прослушивать их примитивной полой трубкой ("дышите - не дышите"). Можно прослушивать их, используя более продвинутый стетоскоп. 🩺 Но для более-менее серьёзных исследований требуются установки для рентгенографии, компьютерной томографии (КТ) или магнитно-резонансной томографии (МРТ). Назначение всех этих инструментов - выявлять аномалии в лёгких (можно условно назвать их "средствами детектирования уязвимостей лёгких"), однако реализация этих инструментов требует совершенно разного технологического уровня, совершенно разных финансовых затрат, а сами инструменты обеспечивают несопоставимый уровень качества детектирования проблем. В медицине ни у кого не набирается наглости выдавать обычный стетоскоп за современный аппарат МРТ или КТ. К сожалению, в кибербезопасности - области гораздо более новой, чем медицина, и гораздо менее регулируемой, попытки выдать наспех слепленную суррогатную поделку за зрелое решение - вполне обычное дело. Так на рынке появляются VM-продукты с очень примитивной функциональностью детектирования, которые превращают процесс управления уязвимостями в профанацию. 🤦‍♂️ Хочется надеяться, что постепенная стандартизация процесса детектирования уязвимостей, а также развитие программ (обязательной?) сертификации средств анализа защищённости с проверкой их функциональных возможностей, сделают продажу таких "котов в мешке" невозможной. 🙏 Но пока, к сожалению, оценка качества детектирования остаётся делом самих клиентов. ➡️Ⓜ️ MAX | @avleonovrus #Detection #VMprocess #VMmyth

Почитал принятый 8 июля ФЗ "О поддержке развития технологий искусственного интеллекта в Российской Федерации". С мнением, что он написан для создания монополии (вернее дуополии) на ИИ для Сбера и Яндекса, я не согласен. Там действительно вводятся требования к "суверенным моделям" (посерьёзнее) и "национальным моделям" (послабее), но я бы не сказал, что в этих требованиях содержится что-то невыполнимое. ИМХО, эту инициативу по регулированию ИИ можно только приветствовать. Конечно, нужно форсированно развивать отечественные компетенции в ИИ, а не подсаживаться на зарубежные модели, а тем более сервисы. Оставьте Gemini, ChatGPT, Grok и прочее "для дома, для семьи", а в важных для страны областях будьте любезны использовать суверенное и национальное. 😉 Национальным и суверенным моделям будут предусмотрены преференции и меры поддержки. Пока самая большая и явная плюшка - снятие вопросов по авторскому праву на материалы, используемые при обучении моделей: "2. Не является нарушением авторских и (или) смежных прав обращение к информации, содержащейся в объектах авторского и (или) смежного права, в целях практического применения положений, составляющих содержание объектов авторского и (или) смежного права, включающее в том числе в рамках компьютерной обработки извлечение, сравнение, классификацию и анализ закономерностей, тенденций и корреляций, содержащихся в этих объектах авторского и (или) смежного права, а также воспроизведение посредством краткосрочной записи в память электронных вычислительных машин исключительно для обучения суверенной и (или) национальной больших фундаментальных моделей искусственного интеллекта при условии, если разработчиком используется экземпляр такого произведения, полученный им правомерно, либо если этот объект авторского и (или) смежного права был доведен до всеобщего сведения и доступен для анализа без ограничения техническими средствами." Весьма любопытно, насколько подробно в документе прописаны традиционные ценности: "Статья 4. Общие принципы правового регулирования отношений в сфере разработки, внедрения и применения больших фундаментальных моделей искусственного интеллекта. Правовое регулирование отношений в сфере разработки, внедрения и применения больших фундаментальных моделей искусственного интеллекта основывается на следующих принципах: ... 6) учет и уважение традиционных российских духовно-нравственных ценностей - обеспечение применения больших фундаментальных моделей искусственного интеллекта на основе таких ценностей, как жизнь, достоинство, права и свободы человека, патриотизм, гражданственность, служение Отечеству и ответственность за его судьбу, высокие нравственные идеалы, крепкая семья, созидательный труд, приоритет духовного над материальным, гуманизм, милосердие, справедливость, коллективизм, взаимопомощь и взаимоуважение, историческая память и преемственность поколений, единство народов России;" Вполне себе формулировки государственной идеологии ("суверенного традиционализма"?), которой стоило бы руководствоваться не только при регулировании искусственного интеллекта. 😉 ➡️Ⓜ️ MAX | @avleonovrus #AI #Sber #Yandex #ideology

Узнал сегодня, что при МГТУ им. Баумана организуются летние образовательные программы по Информационной Безопасности для школьников (что-то типа пионерских лагерей). Для 7-8 классов длительность 1 неделя, для 9-11 классов длительность 1-2 недели. Занятия будут вести преподаватели кафедры ИУ10 "Защита информации", приглашённые эксперты и специалисты из ведущих компаний отрасли. Участники программы погрузятся в мир информационной безопасности и на практике освоят её основные направления. Они будут расследовать киберинциденты, анализировать цифровые следы, разбирать реальные кейсы, а также решать CTF- и олимпиадные задачи. Полученные знания ребята применят, работая над собственными командными проектами. Также они побывают на профильных экскурсиях, познакомятся с ИБ-компаниями и пообщаются с экспертами отрасли. Я тоже планирую поучаствовать в программе в качестве эксперта и рассказать про Управление Уязвимостями. 🙂 В завершение программы участники представят и защитят свои проекты на итоговом выступлении. Лучшие проекты старшеклассников будут рекомендованы для участия в заключительном этапе олимпиады "Шаг в будущее" по профилю "Инженерное дело: информационная безопасность и криминалистика". 😉 Всё это будет проходить в новых кампусах Бауманки. В общем, если ваш ребёнок интересуется информационной безопасностью, обратите внимание. Хорошая возможность познакомиться с профессией. Смены стартуют с 13 июля, последняя начнётся 27 июля. Организаторы говорят, что на первую смену набрали больше, чем планировали, а вот на вторую и третью ещё есть свободные места. Для подписчиков канала по коду "avleonovrus" предусмотрена скидочка. 😇 ➡️Ⓜ️ MAX | @avleonovrus #education #BMSTU #BAUMANTECH #CTF #родительство

Мой канал "Управление уязвимостями и прочее" попал в тематическую папку Telegram-каналов ТИПИ-COMPANY. В подборке представлены каналы по следующим тематикам: • 🔍 OSINT (разведка по открытым источникам) • 💻 Offensive Security • ⚠️ Управление уязвимостями • 🐍 Python и автоматизация • 📊 Data Science Выбирайте понравившиеся каналы или подписывайтесь сразу на все: https://t.me/addlist/faX2lD-FcQk5NTQy Пока специалисты используют ИИ для защиты, мошенники тоже активно осваивают новые инструменты. 🤖 К сожалению, Gemini уже оказался частью одной из крупных мошеннических схем - Google подаёт в суд после того, как с его помощью были обмануты более 100 000 человек. ⚖️ ➡️Ⓜ️ MAX | @avleonovrus #CyberSecurity #InfoSec #VulnerabilityManagement #VulnMgmt #OSINT #OffensiveSecurity #Python #DataScience #Telegram #TelegramChannels #SecurityResearch #AppSec #BlueTeam #RedTeam #DevSecOps

Посмотрел короткий ролик с демонстрацией ОС "Альт Мобильный" на смартфонах OnePlus 6T, Xiaomi Redmi Note 12 Pro 4G и PinePhone, а также портативных консолях Powkiddy и Anbernic. Ролик был снят на XIII научно-практической конференции OSday, прошедшей в начале июня. ALT Mobile выглядит прикольно - вполне себе достойный кандидат на роль Национальной Мобильной Операционной Системы. Насколько я понимаю, устройства на базе Rockchip (PinePhone Pro, PinePhone, PineTab 2) являются референсными для разработки Мобильного Альта. А вот портирование на устройства на процессоре Snapdragon (OnePlus 6T и Xiaomi Redmi Note 12 Pro 4G) было выполнено усилиями сообщества. Новый OnePlus 6T сейчас продаётся примерно за 25 000 ₽ (на Ozon есть варианты примерно за 10 000 ₽, но есть подозрения, что это refurbished), а Xiaomi Redmi Note 12 Pro 4G — примерно за 13 000 ₽. Это, к слову, о том, сколько сейчас стоит взять устройство на поиграться. 😉 Имхо, комбинация более-менее стандартного и доступного китайского железа с отечественными ОС - это сейчас наиболее жизнеспособный вариант создания массовых устройств для физических лиц. Но, конечно, хотелось бы, чтобы в продаже появились устройства с уже предустановленной ALT Mobile, т. к. самостоятельную установку осилят не только лишь все. На устройствах работают приложения из репозитория Сизиф, а также Android-приложения, запускаемые через Waydroid. Waydroid - это свободный и открытый уровень совместимости, предназначенный для запуска Android-приложений в операционных системах на базе Linux. В отличие от традиционных эмуляторов, Waydroid использует контейнерную технологию LXC, что позволяет запускать Android непосредственно на ядре хост-системы и обеспечивает производительность, близкую к нативной. Помимо иконок приложений, типичных для GNOME Shell, на скриншотах можно рассмотреть Google Play, а также Telegram. Telegram там, скорее всего, установлен как нативный Linux-клиент. Было бы очень интересно посмотреть, как через Waydroid работают RuStore и наиболее популярные отечественные приложения. 😉 ➡️Ⓜ️ MAX | @avleonovrus #AltMobile #ALTLinux #Linux #Android #Waydroid #GNOME #RuStore #Smartphones #opensource #НМОС #Rockchip #Snapdragon #PinePhone #PineTab #OnePlus #Xiaomi #XiaomiRedmiNote #Powkiddy #Anbernic #mobile