На Хабре вышла статья о том, как MaxPatrol Carbon использовался при подготовке инфраструктуры для кибербитвы Standoff 17

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

На Хабре вышла статья о том, как MaxPatrol Carbon использовался при подготовке инфраструктуры для кибербитвы Standoff 17

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

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

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

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

🔹 проверки запланированных сценариев;
🔹 поиска непредусмотренных путей атаки.

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

🔻 возможность компрометации дополнительной учётки;
🔻 возможность эксплуатации уязвимости Nginx;
🔻 ошибка в настройке правил сетевого доступа.

Оказалось, что MaxPatrol Carbon, изначально предназначенный для поддержания инфраструктуры в максимально безопасном состоянии, можно использовать и для ещё более сложной задачи - поддержания её в "контролируемо уязвимом" состоянии. 😉

На конференции 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-проверок;
🔹 обновление карточек хоста;
🔹 новые возможности анализа и экспорта данных об уязвимостях;
🔹 доработка политик автоматизации, интеграций и дашбордов;
🔹 обновление агента из интерфейса;
🔹 мастер первичной настройки.

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

Поделюсь впечатлениями от конференции ISCRA Talks 2026, на которой я вчера выступил

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

Поделюсь впечатлениями от конференции ISCRA Talks 2026, на которой я вчера выступил

Поделюсь впечатлениями от конференции ISCRA Talks 2026, на которой я вчера выступил. Площадка, Конгресс-центр МГТУ им. Н. Э. Баумана, мне очень понравилась. Конференция проходила в двух красивых и просторных залах на втором этаже. Экраны - идеальные. Большие и яркие. Не то что убитые блеклые проекторы, которые, к сожалению, всё ещё встречаются на некоторых ИБ-конфах. Микрофоны и кликеры тоже работали без сбоев. Таймслоты были очень щедрые - целый час. 🔥

В спикерском подарке было много тематического и крутого мерча. Очень приятно, большое спасибо! 🙂

В холле работала небольшая выставочная зона со стендами НТЦ "Вулкан", "Аквариус" и (ВНЕЗАПНО 😮) Романа Панина, автора канала "Пакет безопасности". С Романом очень приятно пообщались про рынок VM и ИБ-блогинг. Вообще, идея, что у канала может быть стенд на конференции (не обязательно отдельный), как по мне, супер крутая. ⚡️ Это открывает множество интересных форматов взаимодействия и возможностей для продвижения. 🚀 Организаторам конференций на заметку. 😉

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

Из минусов - видеозапись не велась. 🙁 Что-то у организаторов здесь не срослось. Это, конечно, весьма печально, потому что было два потока, и посмотреть вживую всё интересное было физически невозможно. Много хорошего контента таким образом потерялось. Имхо, видеозапись - это must have, даже если её делают просто со смартфона на штативе. Да пусть бы даже и без штатива. Ну, кроме мероприятий, где запись намеренно не ведётся из-за того, что контент не предназначен для широкого круга.

Проблему с отсутствием видеозаписи своего доклада я частично решил тем, что записал аудио с гарнитуры смартфона. Вроде получилось слушабельно. Теоретически можно ещё нейронками попробовать поднять качество. У кого есть положительный опыт в этом - поделитесь, пожалуйста, в комментариях. Так что можно наложить на аудиозапись слайды и получить видяшку. Если считаете, что мне есть смысл этим заморочиться, поставьте сердечко посту. 😉

В целом впечатление от конференции очень положительное. Большое спасибо InfoSec Club "Ra" за организацию! С удовольствием бы принял участие в следующем году! Как по мне, было бы здорово, если бы ISCRA Talks постепенно выходила за рамки формата мероприятия, ориентированного в основном на студентов МГТУ, при этом сохраняя тесную связь с университетом. Кажется, все возможности для этого уже есть. 😉

Проголосовал на выборах в Госдуму и на местных выборах через систему дистанционного электронного голосования (ДЭГ)

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

Проголосовал на выборах в Госдуму и на местных выборах через систему дистанционного электронного голосования (ДЭГ)

Проголосовал на выборах в Госдуму и на местных выборах через систему дистанционного электронного голосования (ДЭГ). Чётко, быстро, удобно. 👍 Основные шаги показал на иллюстрации.

Для участия в электронном голосовании до 14 сентября нужно было подать заявку на Госуслугах - буквально в пару кликов.

Но без школьного актового зала, долгих поисков фамилии в "амбарных книгах", изучения бюллетеней в кабинках, пропихивания заполненных бюллетеней в урны и прочих прелестей оффлайнового волеизъявления, конечно, уже совсем не тот вайб. 🙂

А вы уже проголосовали? Пойдёте?

В эту субботу я собираюсь выступить на ИБ-конференции "ISCRA Talks 2026" в МГТУ им. Баумана.

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

В эту субботу я собираюсь выступить на ИБ-конференции ISCRA Talks 2026 в МГТУ им. Баумана.

В эту субботу я собираюсь выступить на ИБ-конференции "ISCRA Talks 2026" в МГТУ им. Баумана. Это мероприятие организует бауманский InfoSec Club "Ra" aka ISCRA (официальный канал). В партнёрах кафедра ИУ8, которую я окончил в 2009 году. 😇

Мой доклад будет называться "Пять мифов Vulnerability Management-а". Он основан на серии постов про качество детектирования уязвимостей, скорость сканирования активов, поиск компромисса с бизнесом и IT, эффективные способы доказывать необходимость VM-а, не требующие устранения уязвимости. Ну и про Exposure Management я тоже добавлю. 😉

Я уже выступал с докладом про VM на "ISCRA Talks" в 2023 году (есть видео). Было очень лампово, надеюсь, и в этом году будет не хуже. 🙂 Место проведения - конгресс-холл в новом комплексе зданий МГТУ. Трансляции не будет, но запись обещают.