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

Коллеги из Inseca перезапускают курс по Управлению Уязвимостями

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

Коллеги из Inseca перезапускают курс по Управлению Уязвимостями

Коллеги из Inseca перезапускают курс по Управлению Уязвимостями. Старт 23 августа. Я тестировал этот курс в конце 2023 года, впечатления были весьма приятные. 🙂 Добротный практический курс для "вкатывания" в VM: "проводят за ручку" по всем основным шагам. 👍

Со времени моего прохождения курс значительно расширили и улучшили (в том числе и по моим рекомендациям 😇):

🔹 Процессы. Добавили урок по приоритизации устранения уязвимостей с учётом контекста инфраструктуры организации и риск ориентированным подходом, а также практическую работу "Приоритизация и построение плана устранения уязвимостей […] в типовой организации". Про подходы и инструменты приоритизации расскажет сам Александр Редчиц! 🔥👍

🔹 Продукты. Добавили урок по работе с Faraday. Для работы с Vulners.com будет доступна Ed-лицензия.

🔹 Практика. Добавили задание по поиску поддоменов, анализу DVWA и эксплуатации EoP в Windows (CVE-2017-0213).

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

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

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

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

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

➡️ В качестве примера рекомендую ознакомиться с эпичной историей, как Игорь Агиевич сдавал уязвимость в блокчейне 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 может включать проверку значений в реестре. Т.е. не только версии.

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