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

Иногда общение стоит минимизировать

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

Иногда общение стоит минимизировать

Иногда общение стоит минимизировать. Главная проблема в работе с уязвимостями - это НЕ сами уязвимости. Это необходимость постоянно общаться с людьми, которые этого общения не хотят и которым ты не нравишься. 🫩 Это актуально и при пушинге устранения уязвимостей в инфраструктуре, и при сдаче-приёмке уязвимостей, найденных в ходе багбаунти.

Поэтому я сторонник того, чтобы неприятное общение максимально сокращать и формализовывать. Игры в "докажи-покажи" отнимают массу сил и времени, а когда общение неизбежно заходит в тупик, обе стороны всё равно начинают действовать формально. 🤷‍♂️ Так почему бы не поступать так с самого начала? 😏

➡️ В качестве примера рекомендую ознакомиться с эпичной историей, как Игорь Агиевич сдавал уязвимость в блокчейне Hyperledger Fabric (CVE-2024-45244). Имхо, вместо общения в такой ситуации было бы достаточно скинуть вендору ресёрч и PoC, выждать 3 месяца, зарегать CVE и, без особых рефлексией, сделать full disclosure. 🤷‍♂️😈

Результаты опроса R-Vision: около 80% компаний считают качество сканирования ключевым критерием выбора VM-решений

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

Результаты опроса R-Vision: около 80% компаний считают качество сканирования ключевым критерием выбора VM-решений

Результаты опроса R-Vision: около 80% компаний считают качество сканирования ключевым критерием выбора VM-решений. В опросе приняли участие 83 респондента. Это были ИБ-cпециалисты различного уровня (от линейных сотрудников до CISO), работающие в компаниях разного размера (от SMB до Enterprise) и из различных отраслей (финансы, промышленность, ИТ, ГОСы, нефтегаз, ритейл, транспорт, телекомы, энергетика).

Результаты выглядят вполне адекватно:

🔹 Чем крупнее компания, тем более зрелый там VM-процесс.

🔹 Главный критерий выбора VM-решений - широкое покрытие ОС и приложений. Также важны скорость, стабильность и минимизация фолзов.

Хочется надеяться, что как можно больше VM-вендоров ознакомятся с результатами этого опроса и начнут уделять приоритетное внимание разработке правил детектирования уязвимостей и тестированию качества их работы. 🙏 То есть той базовой функциональности, без которой все остальные "высокоуровневые" фичи не имеют никакого смысла. 🤷‍♂️😉

Вчера провёл традиционный закрытый вебинар по VM-у в рамках Бауманского курса профессиональной переподготовки по направлению "Управление ИБ"

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

Вчера провёл традиционный закрытый вебинар по VM-у в рамках Бауманского курса профессиональной переподготовки по направлению Управление ИБ

Вчера провёл традиционный закрытый вебинар по VM-у в рамках Бауманского курса профессиональной переподготовки по направлению "Управление ИБ". С этого года они работают под брендом БАУМАНТЕХ. 🙂 На вебинаре было около 30 человек. Текущий набор слушателей курса очень сильный. Было заметно, что люди с обширным IT/ИБ-бэкграундом. 🔥 Получил большое удовольствие от общения. Вопросы были отличные. 👍

Отметил для себя, что

🔹 БОСПУУ нужно превращать в текст (методичку?) и прорабатывать вглубь. Это явно востребовано.

🔹 Нужны также образцы корпоративных документов (политик), описывающих VM-процесс в типовой организации. Чтобы, ориентируясь на них, можно было составить свои. Сейчас в паблике такого нет. 🤷‍♂️ А ещё желательно, чтобы эти образцы документов соответствовали и БОСПУУ, и методикам/руководству ФСТЭК, и 117-му приказу ФСТЭК. 🤔

Планов, как обычно, громадьё. 🙂

Сканер уязвимостей с "поиском по версиям в базе" может найти все уязвимости из этой базы?

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

Сканер уязвимостей с поиском по версиям в базе может найти все уязвимости из этой базы?

Сканер уязвимостей с "поиском по версиям в базе" может найти все уязвимости из этой базы? То, что для качественного детектирования нужен "не совсем поиск и не совсем по версиям", я уже расписал ранее. Теперь посмотрим по контенту.

Если в базе сканера 427498 уязвимостей, значит ли это, что сканер может находить их все? Не совсем. 🙂

🔷 Для уязвимости должны быть правила детектирования. Если правила детектирования строятся на основе NVD CPE Configurations, а для какой-то уязвимости в NVD их нет, значит и в сканере их не будет, и сканер уязвимость не обнаружит.

🔷 Должна быть логика определения продукта и его версии. Вот уязвимость CVE-2023-32311 в некотором китайском проекте CloudExplorer Lite, для неё есть логика детектирования: версии = 1.1.0 уязвимы. Но сможет ли сканер узнать инсталляцию с этим CloudExplorer Lite и определить его версию? Не факт. 😉 Поэтому для таких сканеров "наличие уязвимости в базе" != "возможность продетектировать её в инфраструктуре".

Требования к мероприятиям по Управлению Уязвимостями согласно новому приказу ФСТЭК №117

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

Требования к мероприятиям по Управлению Уязвимостями согласно новому приказу ФСТЭК №117

Требования к мероприятиям по Управлению Уязвимостями согласно новому приказу ФСТЭК №117. Приказ устанавливает требования о защите информации, содержащейся в ГИС, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений. Приказ опубликован 17.06.2025, вступает в силу с 01.03.2026. Он заменяет приказ ФСТЭК №17.

Требования к Управлению Уязвимостями раскрыты в пункте 38. Они устанавливают:

🔹 Общую структуру процесса: выявление, оценка, приоритизация, контроль устранения.

🔹 Сроки устранения уязвимостей критического и высокого уровня или исключение возможности их эксплуатации компенсирующими мерами. 24 часа и 7 дней соответственно. Для остальных уязвимостей сроки определяются внутренним регламентом.

🔹 Необходимость сообщать о выявлении уязвимостей, отсутствующих в БДУ ФСТЭК, в течение 5 рабочих дней.

Как видим, требования более чем облегчённые. Особенно если сравнивать с ранними драфтами. 😉

Детектирование уязвимостей "поиском по версиям" - серебряная пуля?

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

Детектирование уязвимостей поиском по версиям - серебряная пуля?

Детектирование уязвимостей "поиском по версиям" - серебряная пуля? Я бы хотел жить в мире, где наличие уязвимости в продукте однозначно определялось простым поиском по его версии в некоторой базе. 🙏 Но реальность сложнее. 🤷‍♂️

🔹 Детектирование по CPE идентификаторам на основе данных из NVD требует расчёта логических выражений (потенциально с большой вложенностью). Это уже не совсем поиск, ближе к расчёту статусов в OVAL-е. 😉

🔹 Для правильного детектирования уязвимостей по версиям пакетов в Linux необходимо сравнивать версии согласно алгоритмам системы управления пакетами (RPM, DEB и т.д.), а не как строки. Тоже не простой поиск. Логика расчёта уязвимостей может требовать проверять версию дистрибутива и версию ядра. Т.е. нужны не только версии продуктов. 🧐

🔹 Детектирование уязвимостей Windows может включать проверку значений в реестре. Т.е. не только версии.

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

При всём моём принятии любых подходов к детектированию уязвимостей, есть одна вещь, которая мне однозначно не нравится

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

При всём моём принятии любых подходов к детектированию уязвимостей, есть одна вещь, которая мне однозначно не нравится

При всём моём принятии любых подходов к детектированию уязвимостей, есть одна вещь, которая мне однозначно не нравится. Когда VM-вендор реализует некоторый подход к детектированию (условный Best Detection & Scanning Method 😏) и начинает применять его везде и всегда как самый лучший и правильный.

Частенько оказывается, что гибкость реализованного подхода недостаточна, чтобы получать качественные результаты детектирования уязвимостей для некоторых типов активов. Гладко было на бумаге, да забыли про овраги. 🤷‍♂️

Правильным решением такое ситуации выглядит:

🔹 Публично признать проблему, покаяться перед клиентами.
🔹 Реализовать подход, обеспечивающий наилучшее качество детектирования.

Но VM-вендоры могут вместо этого включать режим "пренебречь - вальсируем". 😐 Тоже понятно почему: доработка требует ресурсов, а клиенты фолсы могут и не заметить. 😉 Такие кейсы, имхо, следует аккуратно подсвечивать и стимулировать вендоров к повышению качества детектирования.