Архив метки: VulnerabilityManagement

Тоже напишу об уязвимости VMmanager 6, через которую поломали инфраструктуру FirstVDS

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

Тоже напишу об уязвимости VMmanager 6, через которую поломали инфраструктуру FirstVDS

Тоже напишу об уязвимости VMmanager 6, через которую поломали инфраструктуру FirstVDS. FirstVDS - провайдер VDS-хостинга, позволяющий арендовать виртуальные серверы для размещения сайтов, запуска приложений и решения других задач. 18 октября в канале компании сообщили об инциденте безопасности. Днём ранее, 17 октября, злоумышленники воспользовались уязвимостью в системе управления виртуализацией VMmanager 6, получили доступ к части инфраструктуры и запустили на некоторых серверах программу для кражи данных.

VMmanager - продукт иркутской компании ISPsystem, входящей в группу компаний "Астра". Хостинг-провайдеры используют его для создания виртуальных серверов и управления ими. Эксплуатация уязвимости (обозначу как "VMleaker6") позволила злоумышленникам получать доступ к серверам клиентов, в том числе к дискам виртуальных машин. По имеющимся данным, вредоносная программа подключала диски в режиме чтения и копировала хранившуюся на них информацию на сервер злоумышленников. Среди потенциально скомпрометированных данных - файлы, пароли, ключи доступа, токены, конфигурационные файлы, базы данных, резервные копии и данные криптокошельков. 😱

В таких ситуациях возможны два варианта: либо уязвимость была известна, но FirstVDS не установили обновление безопасности вовремя, либо злоумышленники проэксплуатировали 0day-уязвимость, от которой провайдер не мог защититься в рамках Vulnerability Management процесса.

Судя по всему, мы имеем дело со вторым вариантом:

🔻 Ещё 14 октября в ИБ-каналах ходили неподтверждённые данные о 0day-уязвимости VMmanager 6, проэксплуатированной у нескольких хостинг-провайдеров и позволяющей злоумышленнику получить root-доступ к гипервизору, то есть доступ ко всем виртуальным серверам на ноде. Также сообщали, что уязвимость эксплуатируется через интерфейс панели, поэтому под ударом те хостеры, которые дают клиентам прямой доступ к ней.

🔻 Эксперты FirstVDS сообщали о промежуточном патче и работе ISPsystem над окончательным исправлением.

🔻 В последние несколько дней ISPsystem выпускает обновления безопасности VMmanager одно за другим. С 14 октября были выпущены обновления 2026.09.1-1, 2026.09.1-2, 2026.09.1-3, 2026.09.1-4 и 2026.09.1-5. Последние четыре обновления были выпущены начиная с 18 октября (раз в день и два раза в день). При этом не указано, какие именно уязвимости исправляются, - приведён только текст "Исправление ошибок безопасности".

Что тут скажешь: от эксплуатации 0day-уязвимостей никто не застрахован. Злоумышленник может самостоятельно наресёрчить уязвимость в используемом ПО или купить эксплойт на чёрном рынке. Особенно опасны ситуации, когда админка доступна из внешней сети или компрометация инфраструктуры провайдера клиентом-злоумышленником позволяет получить доступ к данным других клиентов. Тут напрашивается параллель с недавней RCE в cPanel (CVE-2026-87899), приводившей к компрометации клиентов shared-хостингов.

К FirstVDS особых вопросов нет: они обнаружили инцидент, сообщили о нём и дали клиентам рекомендации. К ISPsystem вопросов больше. Вендор выпускает обновления безопасности VMmanager, но публичных бюллетеней с описанием исправленных уязвимостей нет. В БДУ ФСТЭК информация о новых уязвимостях, связанных с инцидентом, тоже пока не появилась. Это выглядит как silent patching. 😔 ИМХО, для зрелого вендора такой подход недопустим: нужны публичные бюллетени с описанием уязвимостей, исправлений и workaround-ами. А пока нет даже новости на сайте. 🤷‍♂️ Будем следить за развитием ситуации и ждать открытой коммуникации от вендора.

Upd. Новость добавили.

Бизнес не способен формулировать требования безопасности: ни физической, ни информационной

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

Бизнес не способен формулировать требования безопасности: ни физической, ни информационной

Бизнес не способен формулировать требования безопасности: ни физической, ни информационной. Продолжая тему прилётов по дата-центрам, хотелось бы вот что сказать. Почему в Советском Союзе строили мосты так, что их и сейчас крайне сложно разрушить ракетами, а тем более беспилотниками? Почему строили промышленные объекты, тот же "Азовсталь", с огромными подземными сооружениями, разрушить которые налётами также крайне сложно? Почему станции метро строили с расчётом на то, что их можно использовать как бомбоубежища?

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

А можно ли строить дата-центры так, чтобы прилёты им были не страшны? Глядя на советскую инфраструктуру - конечно, можно. Можно заглублять объекты под землю, можно строить над ними капитальные защитные сооружения. Только на это бизнес отвечает: "Можно. А зачем?" Всё это увеличивает стоимость строительства. Бизнес считает деньги и задаёт закономерный с его точки зрения вопрос: "Как эти капитальные затраты будут окупаться?"

И здесь можно провести параллель с управлением уязвимостями информационной инфраструктуры. Отсутствие физической защиты, рассчитанной на то, что при прилёте в здание объект должен продолжать работу, - это ведь тоже уязвимость (экспозиция). Риски, связанные с ней, менеджмент бизнеса считает маловероятными и принимает решение ничего не делать. А когда риск реализуется, всё, что может сделать менеджмент, - это развести руками и сказать: "Ой, а мы что-то на это не закладывались". А почему вы не закладывались? Разве не было очевидно, что если не заниматься физической защитой объектов, то при прилёте дата-центры будут выходить из строя, а это нанесёт ощутимый ущерб организациям по всей стране?

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

Моё мнение: бизнес самостоятельно не может формулировать стандарты безопасности. Он всегда стремится в моменте максимизировать прибыль. А безопасность всегда стоит денег. Это касается и физической, и информационной безопасности. Если дать бизнесу возможность чего-то НЕ делать, бизнес и не будет этого делать. Все риски будут приниматься как маловероятные. А в случае крупного инцидента менеджмент будет разводить руками. В крайнем случае будут просто катапультироваться на другое тёплое место с "золотым парашютом". 😏

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

Напишу несколько слов о прошедшей вчера конференции "ПРОВЕРКА НА ПРОЧНОСТЬ: практика анализа защищённости"

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

Напишу несколько слов о прошедшей вчера конференции ПРОВЕРКА НА ПРОЧНОСТЬ: практика анализа защищённости

Напишу несколько слов о прошедшей вчера конференции "ПРОВЕРКА НА ПРОЧНОСТЬ: практика анализа защищённости". Мне очень понравилось! Как и "Территория безопасности", это мероприятие ориентировано на общение. При этом я, пожалуй, ещё не был на конференциях, где Vulnerability Management-у было бы посвящено столько стендов, докладов и дискуссий.

Очень приятно, что мне оказали честь открыть мероприятие вместе с Алексеем Качалиным перед общим залом. Фактически с keynote. 😇 Алексей рассказал о ключевых этапах развития VM и стратегии на будущее, а я - о методах приоритизации уязвимостей, трендовых уязвимостях 2026 года и новом подходе Positive Technologies к приоритизации уязвимостей. Следом прошла пленарная дискуссия об Управлении Уязвимостями с участием CISO ведущих российских компаний. 👍

Что касается дискуссии о VMDR, которую я модерировал, то она также прошла удачно. В ней участвовали как представители заказчиков, так и VM-вендоров.

От заказчиков:

🔹 Дарина Кривошеева, CISO, соцсетей VK
🔹 Владимир Мельников, Head of SOC, Билайн
🔹 Иван Советкин, Head of SOC, МТС Банк

От вендоров:

🔹 Андрей Никонов, заместитель директора, Vulns io
🔹 Кирилл Евтушенко, генеральный директор, Кауч
🔹 Дмитрий Черняков, директор по развитию продуктов, RedCheck
🔹 Зоя Гуревич, руководитель направления, "Лаборатория Касперского"

Начали с того, что обсудили проблемы, с которыми заказчики сталкиваются в процессе Управления Уязвимостями. Поговорили о том, какие у них есть пожелания к вендорам.

Затем перешли к представителям вендоров и начали разбирать отдельные VM-ные вопросы:

🔸 управление активами;
🔸 оценка критичности мисконфигураций;
🔸 возможности автоматизированного устранения уязвимостей;
🔸 использование ИИ для подтверждения эксплуатируемости уязвимостей;
🔸 применение ИИ и автономных агентов для выполнения операций в инфраструктуре.

Казалось бы, целый час - много. Но спикеров было немало, а тема обширная. Был риск не успеть обсудить всё или превратить дискуссию в формальный опрос. К счастью, всё получилось! Участники успели высказаться по всем темам, поспорить и обсудить разные подходы. И мы почти уложились в тайминг. 😇

Что отметил на стендах:

🔻 На стенде Positive Technologies представили VM-ные продукты компании, включая MaxPatrol VM, MaxPatrol Carbon и PT Dephaze. Особенно понравилась интерактивная визуализация того, как различные инструменты обнаружения и анализа уязвимостей расширяют контроль над инфраструктурой и помогают прогнозировать действия злоумышленников. Если будете сегодня или завтра на PSD, обязательно зацените её на стенде MaxPatrol Carbon! 😉

🔻 Vulns io представили технологию обновления Windows-инфраструктуры без WSUS, функциональность управления конфигурациями и концепцию Real-Time VM.

🔻 RedCheck (АЛТЭКС-СОФТ) рассказали о новых возможностях управления конфигурациями в RedCheck VM.

🔻 Кауч расширили поддержку высокоуровневых стандартов и улучшили работу с ними в рамках обновления инструментов управления конфигурациями.

Конечно, каждую из этих новинок стоит отдельно разобрать подробнее. 🙂

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

Спасибо всем участникам, а особенно - участникам дискуссии о VMDR, которую я модерировал. Было очень приятно и интересно пообщаться! 😇

Следующим мероприятием, в котором я собираюсь поучаствовать, будет форум "ПРОВЕРКА НА ПРОЧНОСТЬ: практика анализа защищённости"

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

Следующим мероприятием, в котором я собираюсь поучаствовать, будет форум ПРОВЕРКА НА ПРОЧНОСТЬ: практика анализа защищённости

Следующим мероприятием, в котором я собираюсь поучаствовать, будет форум "ПРОВЕРКА НА ПРОЧНОСТЬ: практика анализа защищённости". Пройдёт это мероприятие 14 октября в "Холидей Инн Сокольники". Фактически это спин-офф "Территории Безопасности" с фокусом на работе с уязвимостями во всех проявлениях. 😇

В программе - дискуссии, доклады и мастер-классы о реальной оценке защищённости, управлении уязвимостями (и экспозициями), анализе поверхности атаки, выборе методов проверки (аудит, пентест, Red Team, Purple Team, Bug Bounty), применении ИИ и автоматизации, метриках, защите АСУ ТП, проверке подрядчиков и правовых аспектах этичного хакинга.

В общем, наконец-то мы дождались большой нейтральной конфы, где VM/CTEM будет непосредственно в фокусе, а не где-то сбоку. 🤩🥳

Мои активности:

🔹 Выступлю с 20-минутным докладом "Трендовые уязвимости в 2026 году: как определить, что действительно важно". Расскажу о различных методах оценки критичности уязвимостей, о трендовых уязвимостях текущего года и о том, как мы в Positive Technologies их отбираем. 😉🤫

🔹 Буду модерировать часовой круглый стол "VM, DETECTION & RESPONSE: Придёт ли к нам реальная автоматизация?". Побеседуем о перспективном и наболевшем в VM/VMDR/CTEM. Со стороны вендоров заявлены Андрей Никонов из Vulns io VM, Дмитрий Черняков из RedCheck, Кирилл Евтушенко из Кауч. Со стороны клиентов заявлены Владимир Мельников из SOC Билайн, Дарина Кривошеева из VK, Иван Советкин из МТС Банк. Состав топовый, должно пройти интересно. Накидывайте в комментарии каверзные вопросы. 😏

Все на ПнП 14 октября! 🏃‍♂️

На конференции IT Elements эксперты компании Инфосистемы Джет представили "Фреймворк антихрупкой ИТ-архитектуры", учитывающий состояние процесса Управления Уязвимостями в организации

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

На конференции IT Elements эксперты компании Инфосистемы Джет представили Фреймворк антихрупкой ИТ-архитектуры, учитывающий состояние процесса Управления Уязвимостями в организации

На конференции IT Elements эксперты компании Инфосистемы Джет представили "Фреймворк антихрупкой ИТ-архитектуры", учитывающий состояние процесса Управления Уязвимостями в организации. Фреймворк включает в себя 7 стратегий по четырём направлениям:

🔹 Подготовка к вторжению - 1. Системное развитие и контроль, 2. Подготовка и прогнозирование.
🔹 Слева от вторжения - 3. Вовлечение и нападение, 4. Защита, замедление, сдерживание.
🔹 Справа от вторжения - 5. Обнаружение и реагирование.
🔹 После вторжения - 6. Восстановление, 7. Адаптация и перестройка.

Эти стратегии раскладываются в 33 домена, которые, в свою очередь, раскладываются в 390 практик.

Чтобы замерить индекс антихрупкости для своей организации, можно воспользоваться специальным интерактивным опросником. Индекс оценивает способность компании пережить кибератаку, продолжать работу в её условиях и восстановиться после неё. По итогам заполнения опросника получаем индекс от 0 до 100%, разбор по направлениям защиты и сравнение с другими участниками. Отраслевой уровень обновляется автоматически по мере накопления ответов респондентов. Индекс рассчитывается по открытой методике. Опросник должен заполнять CISO. Вопросы однотипны, варианты ответов: "Да", "Частично", "Нет", "Неприменимо", "Не знаю".

Теперь пройдёмся по 13 практикам, которые непосредственно связаны с Управлением Уязвимостями. Они находятся в разделе Слева от вторжения -> 4. Защита, замедление, сдерживание -> 4.4 Непрерывная работа с уязвимостями.

📄 Формализация процесса, ответственные за устранение и сроки устранения

4.4-1 Регламентирован и реализуется процесс управления уязвимостями, определяющий порядок их выявления, оценки критичности, планирования и контроля устранения. Определяются ответственные за устранение уязвимостей и реализацию исправлений, а также целевые сроки, согласованные службами ИБ и ИТ

В опроснике: 49. Регламентирован и реализуется процесс управления уязвимостями. Определены ответственные за устранение уязвимостей и реализацию исправлений, а также целевые сроки, согласованные службами ИБ и ИТ

📄 Задачи на сканирование

4.4-2 Определен перечень, приоритеты и сроки сканирования каждого актива/типов активов. В область сканирования включены все активы, обеспечивающие критически значимые процессы организации

В опроснике нет.

📰 Отслеживание информации об уязвимостях

4.4-3 Определены источники информации об уязвимостях (например, БДУ ФСТЭК России, уведомления от регуляторов, сайты производителей ПО, каналы СМИ и др.). Информация из этих источников систематически анализируется на предмет применимости к активам организации, выявленные релевантные уязвимости регистрируются

В опроснике нет.

🚨 Экстренная обработка уязвимостей

4.4-4 Документирована и реализуется процедура экстренной обработки критических уязвимостей, определяющая порядок оповещения ИБ и ИТ, экстренной оценки применимости уязвимости, реализации временных защитных мер и координации действий с процессом кризисного реагирования.

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

🔎 Сканирование на наличие уязвимостей

4.4-5 Функционирует процесс регулярного автоматизированного поиска уязвимостей. Поиск выполняется автоматизированными средствами, использующими актуальные базы данных (сканеры уязвимостей).

В опроснике: 51. Функционирует процесс регулярного автоматизированного поиска уязвимостей. Поиск выполняется автоматизированными средствами, использующими актуальные базы данных.

💿 Базовые образы

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

В опроснике нет.

⚖️ Продвинутая приоритизация уязвимостей

4.4-7 Приоритизация устранения уязвимостей выполняется по риск-ориентированным критериям, включая критичность актива, последствия эксплуатации, наличие доступных способов эксплуатации и техническую оценку уязвимости. Приоритеты используются для определения сроков устранения и контроля выполнения.

В опроснике: 52. Приоритизация устранения уязвимостей выполняется по риск-ориентированным критериям. Приоритеты используются для определения сроков устранения и контроля выполнения.

🔐 Сканирование с аутентификацией

4.4-8 Для обнаружения уязвимостей применяется аутентифицированное сканирование узлов, при котором средство сканирования получает контролируемый доступ к системе для более точного выявления уязвимых компонентов и конфигураций.

В опроснике нет.

🔗 Интеграция с GRC

4.4-9 Данные об уязвимостях автоматически синхронизируются с реестром рисков или системой управления рисками (GRC-системой). Изменение статуса уязвимости приводит к пересчету параметров риска и созданию или обновлению карточки риска.

В опроснике нет.

🎫 Интеграция с Task Tracker

4.4-10 Реализована интеграция инструментов сканирования уязвимостей с системой управления задачами. Задачи на устранение уязвимостей формируются автоматически, приоритет задач определяется критичностью уязвимости и значимостью актива.

В опроснике нет.

↪️ Компенсирующие меры

4.4-11 Для уязвимостей, устранение которых невозможно или небезопасно, определяется и применяется набор компенсирующих мер, выбор которых документируется и привязывается к конкретной уязвимости и активу.

В опроснике нет.

💭 План снижения риска

4.4-12 Для унаследованных систем, которые невозможно привести к актуальному уровню безопасности, разработаны и выполняются планы снижения риска. Планы определяют целевое состояние системы (вывод из эксплуатации или замена) и устанавливают временные меры защиты на период ее эксплуатации.

В опроснике нет.

⏱️ Отслеживание сроков устранения

4.4-13 Осуществляется системный контроль соблюдения целевых сроков устранения уязвимостей. Устранение выявленных уязвимостей периодически контролируется, результаты контроля регистрируются.

В опроснике: 53. Осуществляется периодический контроль соблюдения целевых сроков устранения уязвимостей. Устранение выявленных уязвимостей периодически контролируется.

В целом, довольно толковый набор практик. 👍 Единственное, не очень понятно, почему практик больше, чем вопросов в опроснике. Возможно, отобрали самое важное, а может, опросник будут расширять. 🤷‍♂️

В начале сентября коллеги из Cloud Advisor выпустили исследование "Состояние облачной безопасности в России. Анализ защищённости инфраструктур, развёрнутых в российских публичных облаках"

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

В начале сентября коллеги из Cloud Advisor выпустили исследование Состояние облачной безопасности в России. Анализ защищённости инфраструктур, развёрнутых в российских публичных облаках

В начале сентября коллеги из Cloud Advisor выпустили исследование "Состояние облачной безопасности в России. Анализ защищённости инфраструктур, развёрнутых в российских публичных облаках". Cloud Advisor - это вендор отечественного CNAPP (Cloud-Native Application Protection Platform) решения, позволяющего искать на облачных активах (виртуальных машинах и Kubernetes) уязвимости, вредоносный код, секреты и мисконфигурации. Отчёт о состоянии облачной безопасности в России опирается на реальные данные десятков организаций, имеющих не менее 80 виртуальных машин в публичном облаке (Cloud Ru и Yandex Cloud). Всего было проанализировано более 40 000 виртуальных машин. Период исследования - первое полугодие 2026 года.

По уязвимостям результаты следующие:

🔻 83% виртуальных машин имеют уязвимости с CVSS выше 9,0;
🔻 88% организаций имеют на публично доступных машинах уязвимости с CVSS выше 9,0;
🔻 27% организаций до сих пор уязвимы к Log4Shell (CVE-2021-44228);
🔻 42% организаций имеют хотя бы одну виртуальную машину на периметре с ОС, находящейся в статусе EOL (всего EOL-систем в облаках около 9%).

В части Управления Уязвимостями эксперты Cloud Advisor рекомендуют:

🔹 Внедрить регулярное сканирование виртуальных машин и образов контейнеров на уязвимости, используя для этого безагентные cloud native-решения. "Таким образом можно обеспечить 100% покрытие без трудозатрат на установку агентов и настройку SSH-доступов".

🔹 Приоритизировать уязвимости по контексту, а не только по CVSS. Помимо CVSS и наличия эксплойтов рекомендуют учитывать "публичную доступность ресурса, наличие на нём секретов в открытом виде, его права и другие факторы".

🔹 Установить и соблюдать SLA на устранение уязвимостей в зависимости от их критичности. "Без фиксированных сроков CVE накапливаются годами - как это произошло с Log4Shell".

Также эксперты Cloud Advisor обращают внимание, что наибольшую опасность представляют цепочки уязвимостей, ошибок конфигураций и прав доступа, которые в совокупности создают критические пути атаки. Именно такие связки должны стать приоритетом в защите облачной инфраструктуры.

Коллеги из R-Vision выпустили новую версию системы управления уязвимостями R-Vision VM 6.6

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

Коллеги из R-Vision выпустили новую версию системы управления уязвимостями R-Vision VM 6.6

Коллеги из R-Vision выпустили новую версию системы управления уязвимостями R-Vision VM 6.6. В новости на официальном сайте сделан акцент на следующих улучшениях:

🌐 Базовый аудит веб-приложений: обнаружение и инвентаризация веб-ресурсов, выявление связанных уязвимостей.

🐳 Аудит контейнерных сред Docker и Kubernetes, "включая проверку в runtime". Сбор данных о составе и состоянии контейнерной среды, выявление связанных уязвимостей. Результаты отображаются в карточке соответствующего хоста.

💻 Мобильный сканер для контроля уязвимостей в закрытых сегментах без постоянного доступа из центральной VM-системы. Может использоваться на объектах КИИ, в удалённых филиалах, а также для выездных аудитов, пилотных и временных проектов. Устанавливается на ноутбук и позволяет проводить аудит внутри изолированного контура. Поддерживаются режимы сканирования White Box, Black Box, Compliance и Web-аудит. Результаты инвентаризации активов и выявленные уязвимости передаются в центральную инсталляцию R-Vision VM. Рассчитан на проверку до 2000 хостов.

Также заявлены:

🔹 расширение инвентаризации ESXi, vCenter и сетевого оборудования;
🔹 обновление Compliance-проверок;
🔹 обновление карточек хоста;
🔹 новые возможности анализа и экспорта данных об уязвимостях;
🔹 доработка политик автоматизации, интеграций и дашбордов;
🔹 обновление агента из интерфейса;
🔹 мастер первичной настройки.

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