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

Как оценивать, насколько хорошо вендоры ОС описывают уязвимости, найденные/исправленные в ОС?

Как оценивать, насколько хорошо вендоры ОС описывают уязвимости, найденные/исправленные в ОС?

Как оценивать, насколько хорошо вендоры ОС описывают уязвимости, найденные/исправленные в ОС?

При составлении рейтинга предлагаю давать по одному баллу за следующее:

1. Вендор ОС в принципе сообщает клиентам информацию об обнаруженных и исправленных уязвимостях (хотя бы о наиболее критичных).

2. Вендор ОС выкладывает на сайте бюллетени безопасности. То есть на сайте вендора есть публичный раздел, где описывается, что такие-то версии таких-то пакетов исправляют такие-то CVE/BDU-уязвимости.

3. Вендор ОС выкладывает на сайте информацию об уязвимостях в машиночитаемом формате (например, OVAL), достаточную для автоматического детектирования уязвимостей.

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

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

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

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

Хотелось бы сделать наличие бюллетеней безопасности абсолютной нормой для вендоров отечественных ОС. Которых сейчас в реестре Минцифры только по классу 02.09 находится 55. 🫣

Если мы, как комьюнити, начнём это отслеживать, то, с одной стороны, сможем подсветить вендоров ОС, которые ответственно подходят к устранению уязвимостей, информируют пользователей об устранённых уязвимостях и предоставляют необходимую информацию вендорам средств анализа защищённости для разработки правил детектирования. 👍 А с другой стороны, можно будет простимулировать вендоров, у которых в этом отношении всё не очень хорошо. 📣

Возможно, удастся привлечь внимание регуляторов к тому, что для некоторых отечественных ОС нет бюллетеней безопасности, как, зачастую, и обновлений вообще. 🤷‍♂️ И что таким продуктам не место в реестрах. 😉

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

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

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

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

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

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

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

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

Добавил поддержку OVAL-контента для ALT Linux в Linux Patch Wednesday

Добавил поддержку OVAL-контента для ALT Linux в Linux Patch Wednesday

Добавил поддержку OVAL-контента для ALT Linux в Linux Patch Wednesday. Теперь я отслеживаю когда были исправлены те или иные CVE-шки в пакетах ALT Linux и учитываю это при формировании ежемесячных бюллетеней. Чем больше источников данных по исправляемым уязвимостям в Linux дистрибутивах, тем адекватнее становятся бюллетени. 👍 Особенно если эти Linux дистрибутивы независимые, а не деривативы. 😇

Итого, сейчас в генераторе LPW используется 7 источников в формате OVAL:

🔹 Debian
🔹 Ubuntu
🔹 Oracle Linux
🔹 RedOS
🔹 AlmaLinux
🔹 Red Hat
🔹 ALT Linux

И ещё один источник в формате листов рассылки Debian.

С обзором июньского Linux Patch Wednesday я припозднился (в связи с этими доработками и отпуском), но планирую в скором времени его выпустить (upd. выпустил). Тем более что уязвимостей там не так уж много - 598. 🙂

5 моментов про отечественные Linux-дистрибутивы

5 моментов про отечественные Linux-дистрибутивы

5 моментов про отечественные Linux-дистрибутивы. Каждый раз, когда появляется новость про российский Linux-дистрибутив в комментарии приходят хейтеры с криками "Bolgenos!". Типа это ненастоящий дистрибутив. Вот есть какие-то настоящие, а этот нет. Имею сказать следующее:

1. Даже тот самый мемный BolgenOS Дениса Попова по прошествии лет выглядит как вещь, которая вполне имела право на существование в качестве учебного проекта несколько странноватого, но вполне безобидного 16летнего парня. 🤷‍♂️ Ну сделал он сборку Ubuntu с нескучными обоями и переименованными приложениями (где-то вроде даже копирайты затер 😱). Ну сняли про него дурацкий репортаж на региональном ТВ. Это был повод для травли, вот серьёзно?

2. Если какие-то люди собрали очередной Linux-дистрибутив, допустим, на основе Debian, используют его сами и собираются его кому-то продавать, то они в своём праве. Даже если они (о ужас!) не собирают сами пакеты, а продают ванильный Debian с налепленным своим логотипом. Вот даже тогда. Насколько мне известно, ничто сейчас не запрещает это делать. Ни российское законодательство, ни требования регуляторов, ни даже опенсурсные лицензии.

3. Если с этим Linux-дистрибутивом можно комфортно и относительно безопасно (в смысле оперативного исправления уязвимостей, отсутствия явных закладок, обновления с российских серверов) работать, то в общем-то и норм. Если вдруг почему-то нельзя, то это хорошая тема для предметного обсуждения. Ну ещё неплохо бы бюллетени безопасности в формате OVAL, чтобы уязвимости было удобно детектировать. 😇

4. Если маркетинг компании, которая выпустила Linux-дистрибутив, позволяет себе в официальной коммуникации писать, что это какая-то уникальная отечественная ОС, разработанная с нуля, то это, имхо, скверно и достойно порицания. Но на сам дистрибутив это никак не влияет.

5. Я не верю в какие-то прям "хорошие Linux-дистрибутивы". Это ВСЕГДА переупакованный ЧУЖОЙ код от апстримов. В этом отношении прилетела ли ко мне программная закладка непосредственно от разработчика (например, XZ Utils или самого Торвальдса) или от Debian-ов мне, как потребителю, как-то пофигу. В возможности всерьёз контролировать апстрим я не верю. Если вы так здорово закладки можете выявлять, почему вы тогда Linux-овые уязвимости не выявляете? Сотни Linux-овых уязвимостей исправляются каждый месяц, что же вы их не выявляете сами раньше разработчиков? 😏 Использование Linux и опенсурсного софта это всегда некоторый компромисс функциональных возможностей и безопасности. Лучше бы, конечно, своё ядро. Лучше бы, конечно, чтобы и системные компоненты свои. И прикладной софт свой. А раз этого всего нет и не ожидается, то и чего щёки надувать, что вы принципиально лучше тех самых "болгеносов"? 😏

Возможно ли использовать AI для детектирования уязвимостей?

Возможно ли использовать AI для детектирования уязвимостей?

Возможно ли использовать AI для детектирования уязвимостей? Думаю да, но тут нужно определиться, что мы под этим понимаем.

🔻 Если речь идёт об обнаружении ранее неизвестных уязвимостей, о ресёрче, то здесь AI инструменты работают уже сейчас. Буквально на днях, 1 ноября, исследователи из Google Project Zero обнаружили первую реальную эксплуатабельную уязвимость с помощью своего LLM проекта Big Sleep. Это была stack buffer underflow в SQLite. Очень круто и многообещающе. 👍

🔻 Если же речь идёт об известных (CVE) уязвимостях, то задача сводится к генерации чётких правил их детектирования в инфраструктуре. AI должен взять на вход имя продукта и вендора, обнаружить источник данных об уязвимостях, понять структуру данных и как можно из них сгенерировать формальные правила для детектирования (например, на языке OVAL), произвести генерацию и оценить корректность правил. Не выглядит как что-то невероятное, но практических реализаций этого я пока не встречал. 🤷‍♂️

CVE-идентификаторы с пробелом в OVAL-контенте RedOS

CVE-идентификаторы с пробелом в OVAL-контенте RedOS

CVE-идентификаторы с пробелом в OVAL-контенте RedOS. В ходе подготовки отчёта по октябрьскому Linux Patch Wednesday обнаружил, что у меня откуда-то лезут невалидные CVE-идентификаторы с пробелом в конце. Источником оказался OVAL-контент RedOS (7.6 мб). По находится 115 таких проблемных ссылок на CVE. Вряд ли это ошибки при ручном заполнении, видимо ошибка в последних версиях генератора OVAL-контента.

Если вы используете OVAL-контент RedOS, обратите внимание, что такое может быть и потенциально может аффектить Vulnerability Management процесс.

Просьба коллегам из РЕД СОФТ пофиксить проблему и накрутить тесты, что используемые CVE-идентификаторы матчатся регуляркой.

Upd. Коллеги из РЕД СОФТ быстро отреагировали и проблему исправили. 🙂👍