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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями?

4 комментария

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями?

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями? Если б я был регулятор. 🙂

1) Обновления безопасности должны быть. Критичная общелинуксовая уязвимость, должна быть пофикшена и в отечественном дистрибе. Или должно быть опубликовано обоснование, почему она неэксплуатируема.
2) Бюллетени безопасности должны быть. Клиенты должны как-то узнавать какую версию пакета нужно поставить, чтобы избавиться от критичной уязвимости.
3) Бюллетени безопасности должны быть публично доступны. Cпорный момент. Зависит от отношения к "security through obscurity". По мне закрытие доступ к бюллетеням усложняет жизнь исследователям, а злоумышленники все равно их получат через любого клиента.
4) Бюллетени безопасности должны быть доступны в машиночитаемом виде. Желательно в формате OVAL, раз уж он так распространен (RHEL, Suse, Ubuntu, Debian и даже отечественный RedOS)