На конференции 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 году (есть видео). Было очень лампово, надеюсь, и в этом году будет не хуже. 🙂 Место проведения - конгресс-холл в новом комплексе зданий МГТУ. Трансляции не будет, но запись обещают.

В конце прошлой недели вышли ещё два поста, разъясняющие утечку из Metascan-а.

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

В конце прошлой недели вышли ещё два поста, разъясняющие утечку из Metascan-а.

В конце прошлой недели вышли ещё два поста, разъясняющие утечку из Metascan-а. Признаться, когда я писал предыдущий свой пост по поводу этой утечки, у меня оставались непонятки: если данные слил инженер, которого недавно уволили, то почему он выложил не свежие исходники сканера, а исходники 2025 года? 🤔

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

Что тут можно сказать дополнительно к тому, что не следует работать с чудаками?

🔹 Telegram на роль энтерпрайзного мессенджера подходит так себе. Использовать его в рабочих процессах на первый взгляд соблазнительно, но это может привести к большим проблемам. Контролировать его использование сотрудниками можно весьма условно. Отсюда и утечки. Я даже не говорю о том, что администрация Telegram имеет доступ ко всему, что передаётся в чатах, и может предоставлять этот доступ кому угодно. Поэтому, если в вашем рабочем процессе используется ТГ, да и любой бесплатный мессенджер, это весьма скверно. Это нужно запрещать политикой безопасности организации.

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

Также менеджмент Metascan подозревает, что в инциденте замешана компания-конкурент. Не хочется верить, что в российском ИБ-комьюнити такое возможно. Но следствие разберётся.