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

Ходили сегодня в Музейную фабрику пастилы

Ходили сегодня в Музейную фабрику пастилы

Ходили сегодня в Музейную фабрику пастилы. Среди прочих интересных и вкусных активностей перед нами разыграли небольшую зарисовку по рассказу Надежды Тэффи "Сам". Рассказ о том, как отец семейства в целях экономии решил САМ делать пастилу, а не покупать в магазине. Вконец измучился, а получилось малосъедобно и дороже покупной.

У меня это срезонировало с вопросом об in-house разработке средства детектирования уязвимостей, который недавно поднимал Андрей Дугин.

VM-вендоры продают лицензии и имеют возможность использовать эти средства для развития решения и расширения команды разработки. А in-house сканер так и будут пилить 1,5 программиста в свободное от других задач время. До момента, как кто-то из них уволится, и код станет неподдерживаемым легаси. 🤷‍♂️ Ладно ещё делать утилиту для детекта уязвимостей в конкретной системе, с которой не работают коммерческие решения. Но пилить своими силами универсальный сканер уязвимостей - задача амбициозная до безумия.

В отпуске поразмышлял о том, как могла бы выглядеть более жизнеспособная альтернатива OVAL-у - проект SOVA

В отпуске поразмышлял о том, как могла бы выглядеть более жизнеспособная альтернатива OVAL-у - проект SOVA

В отпуске поразмышлял о том, как могла бы выглядеть более жизнеспособная альтернатива OVAL-у - проект SOVA. Хотелось бы взять лучшее от OVAL и кардинально упростить создание контента и сканеров, поддерживающих новый формат. С перспективой конвертации существующего OVAL-контента в SOVA.

Пока основные идеи такие:

📃 Отказаться от XML в пользу JSON, с которым проще работать и автоматически, и вручную.

⚙️ Сохранить основную фишку OVAL-а - статусы дефинишенов определять комбинацией статусов тестов или других дефинишенов.

🧪 Типы тестов вынести из спецификации языка и упростить их заведение. Вплоть до возможности создания тестов с выполнением произвольного bash-скрипта на хосте или выполнением веб-запросов. 😈

🧭 Описание параметров тестов (объектов и стейтов) хранить прямо в блоке с логикой детектирования статуса дефинишена. Тогда не придётся бегать по разным разделам документа, чтобы понять фактическую логику детектирования. И это важнее некоторой избыточности описания. 😉

На сайте Anti-Malware вышла статья Николая Рягина из R-Vision "Как отличить качественную базу уязвимостей от справочника CVE"

На сайте Anti-Malware вышла статья Николая Рягина из R-Vision Как отличить качественную базу уязвимостей от справочника CVE

На сайте Anti-Malware вышла статья Николая Рягина из R-Vision "Как отличить качественную базу уязвимостей от справочника CVE". Мне статья очень понравилась, в лайв-канале я сделал краткую выжимку.

Согласно статье, базы знаний средств детектирования уязвимостей и связанные с ними процессы VM-вендоров могут существенно различаться как минимум по девяти параметрам качества:

1. 📦 Полнота покрытия продуктов
2. 🔄 Частота выпуска обновлений правил детектирования
3. 🌐 Использование источников данных об уязвимостях
4. ✅ Верификация правил детектирования
5. 🧪 Тестирование процесса детектирования
6. 🔍 Прозрачность логики детектирования
7. ⚡️ Скорость исправления ошибок детектирования
8. 🛠 Адаптируемость детектирования под заказчика
9. 📖 Полнота информации по устранению уязвимостей

💡 Имхо, эти параметры могут стать основой для открытого фреймворка, используемого как самими VM-вендорами для самооценки своих решений и процессов, так и клиентами при выборе VM-решений.

Детектировать нужно все уязвимости!

Детектировать нужно все уязвимости!

Детектировать нужно все уязвимости! Частенько натыкаюсь на мнение, что основательный подход к построению VM процесса, например по БОСПУУ, приведёт к тому, что продетектированных в организации уязвимостей будет слишком много, "IT с такими объёмами не справится". А раз так, то не стоит и начинать. 🫠

Мой ответ на это:

🔻 Прежде всего следует поставить вопрос, почему устранять уязвимости (~обновлять системы) является настолько мучительной задачей для IT. Скорее всего, это свидетельство архитектурных проблем, препятствующих внедрению базовых процессов кибергигиены. Невозможность устранять уязвимости - только следствие. 🌝

🔻 Выявлять нужно все уязвимости, но устранять их следует приоритизированно. В первую очередь следует устранять уязвимости, эксплуатация которых наиболее проста и выгодна злоумышленникам. А как это понять? Для этого, по-хорошему, необходимо формировать потенциальные пути атак (attack paths), производить их оценку и приоритизацию. И для этого есть решения. 😉

R-Vision раскрыли информацию о продуктах, поддерживаемых R-Vision VM, в новом разделе справочного портала

R-Vision раскрыли информацию о продуктах, поддерживаемых R-Vision VM, в новом разделе справочного порталаR-Vision раскрыли информацию о продуктах, поддерживаемых R-Vision VM, в новом разделе справочного порталаR-Vision раскрыли информацию о продуктах, поддерживаемых R-Vision VM, в новом разделе справочного порталаR-Vision раскрыли информацию о продуктах, поддерживаемых R-Vision VM, в новом разделе справочного порталаR-Vision раскрыли информацию о продуктах, поддерживаемых R-Vision VM, в новом разделе справочного порталаR-Vision раскрыли информацию о продуктах, поддерживаемых R-Vision VM, в новом разделе справочного портала

R-Vision раскрыли информацию о продуктах, поддерживаемых R-Vision VM, в новом разделе справочного портала.

📰 В "Релизах базы уязвимостей" описываются обновления базы уязвимостей с 1 июля 2024 года (выходят 2 раза в месяц). Для уязвимостей, детектируемых в pentest-режиме, приводятся CVE-идентификаторы.

👁 Текущее состояние базы детектов уязвимостей (мисконфигураций) в ОС, стороннем ПО, СУБД и сетевом оборудовании отображается в контексте профилей сканирования:

🔸 Поиск уязвимостей. Параметры: Наименование, Версия, Рекомендации [по устранению уязвимостей], EoL [поддерживается ли версия продукта вендором], Комментарии [об ограничениях детектирования].

🔸 Тестирование на проникновение. Параметры: Наименование, Обнаружение продукта, Поиск уязвимостей по версии, Сбор дополнительной информации, Подбор учётных данных, Эксплуатационное тестирование.

🔸 Проверка стандартов. Параметры: Наименование и Версия.

Здорово, что эта информация теперь в паблике! 👍👏🙂

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

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

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

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

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

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

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

VM-вендоры и Linux-вендоры: доверять, проверять, стимулировать

VM-вендоры и Linux-вендоры: доверять, проверять, стимулировать

VM-вендоры и Linux-вендоры: доверять, проверять, стимулировать. Моё мнение относительно правильного детектирования уязвимостей в Linux-дистрибах. 🙂

🔹 В идеале бюллетени безопасности (или публичный трекер) Linux-вендора должны содержать информацию обо всех известных уязвимостях во всех пакетах, доступных в репозитории Linux-вендора. И VM-вендор должен детектировать уязвимости в пакетах ОС исключительно на основе этой информации.

🔹 Если VM-вендор в ходе проверок обнаруживает, что в бюллетенях Linux-вендора описаны не все уязвимости, он должен ему об этом сообщить. ✉️ Если реакции нет, VM-вендор должен реализовать правила детектирования по своей логике. В том числе, "опускаясь до базового дистриба".

🔹 При отсутствии реакции VM-вендор должен сообщить регуляторам (ФСТЭК и Минцифры?) о том, что Linux-вендор пренебрегает своими обязанностями по описанию и устранению уязвимостей. Желательно, чтобы это влияло на присутствие ОС в реестре и наличие у неё сертификата. 😉