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

Результаты сканирования RedCheck и ScanOVAL для Windows хостов

Результаты сканирования RedCheck и ScanOVAL для Windows хостов

Результаты сканирования RedCheck и ScanOVAL для Windows хостов. Есть коммерческий VM-продукт RedCheck от АЛТЭКС-СОФТ и бесплатный локальный сканер уязвимостей ScanOVAL от ФСТЭК, который также использует контент от АЛТЭКС-СОФТ. Было интересно посмотреть, а есть ли какая-то разница в результатах сканирования. Возможно какая-нибудь разница в контенте или в работе движка. Сравнение отчетов по CVE-шкам для нескольких тестовых Windows хостов с разной конфигурацией подтвердило: разницы в результатах сканирования нет, совпадение по 100% CVE. Так что, если считать ScanOVAL эталонным сканером, то RedCheck будет полностью соответствовать этому эталону. Уточнение: при сканировании RedCheck-ом использовался транспорт WinRM.

Руководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению Уязвимостями. Что изменилось от проекта к релизу. Часть 2. Что определяет руководство?

Продолжаем увлекательное сравнение. Видим в Общих положениях новый пункт 1.2.

"Руководство определяет состав и содержание работ по анализу и устранению уязвимостей (далее – управление уязвимостями),"

Отмечаем: "управление уязвимостями" = "анализ и устранение уязвимостей" ❗️

"выявленных в

программных,
программно-аппаратных средствах"

Ага, вот куда ПО и ПАС из названия документа переехали. ПО и ПАС относящихся к чему?

"информационных систем,
информационно-телекоммуникационных сетей,
автоматизированных систем управления,
информационно-телекоммуникационных инфраструктурах [м.б. инфраструктур?] центров обработки данных, на базе которых функционируют эти системы и сети (далее – информационные системы)."

Т.е., если у вас есть ИС, ИТС, АСУ, центр обработки данных - будьте любезны внедрить VM для ПО и ПАС. 😉👍

Часть 1

Руководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению УязвимостямиРуководство ФСТЭК по Управлению УязвимостямиРуководство ФСТЭК по Управлению Уязвимостями

Руководство ФСТЭК по Управлению Уязвимостями. Что изменилось от проекта к релизу. Часть 1. Общая структура.

Буду потихоньку делать сопоставление. Если смотреть только на релиз, ничего особенно в глаза не бросается, но изменений довольно много.

1. Скорректировали название. Было "Руководство по управлению уязвимостями программного обеспечения и программно-аппаратных средств в органе (организации)", стало "Руководство по организации процесса управления уязвимостями в органе (организации)". Новое название кажется более удачным. Тут и акцент именно на процесс, и вроде указывать уязвимости чего тоже смысла нет.
2. Общая структура документа не изменилась. Но добавили приложение с описанием BPMN элементов на схемах - полезная вещь.
3. Текстовая часть расширилась. Проект был на 29 страниц, релиз на 33 (включая одну страницу-приложение).

Утвержден методический документ ФСТЭК России "Руководство по организации процесса управления уязвимостями в органе (организации)"

Утвержден методический документ ФСТЭК России "Руководство по организации процесса управления уязвимостями в органе (организации)". Дождались, ура! 🙂 На первый взгляд не сильно отличается от исходного проекта, но нужно аккуратненько посравнивать.

Методические документы регуляторов, связанные с Управлением Уязвимостями

Методические документы регуляторов, связанные с Управлением Уязвимостями. В презентации, которую я сейчас готовлю к ISCRA Talks, будет слайд про документы регуляторов связанные с VM-ом, выпущенные за последние 1,5 года. Если я что-то важное пропустил, напишите мне, пожалуйста, в личку или комментом в пост в ВК.

1. НКЦКИ "Критерии для принятия решения по обновлению критичного ПО, не относящегося к open-source". Рекомендательный алгоритм, помогающий принять решение: установить обновление с риском привнести НДВ (недекларированные возможности)/блокировку функциональности или не обновлять с риском получить эксплуатацию уязвимости. Этого алгоритма я касался в выступлении на PHDays 11 и писал скрипты автоматизации проверок по нему в рамках опенсурсного проекта Monreal.

2. ФСТЭК "Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств". Описывает каким образом можно получить общую оценку критичности уязвимости и выставить требования по оперативности исправления. Я писал комментарии по этой методике.

3. ФСТЭК "Методика тестирования обновлений безопасности программных, программно-аппаратных средств". Описывает какими способами искать НДВ в обновлениях безопасности. Мои комментарии к этой методике: Часть 1, Часть 2, Часть 3.

4. ФСТЭК "Рекомендации по безопасной настройке операционных систем Linux". Рекомендации распространяются на настройку НЕсертифицированных ОС (Debian, Ubuntu, CentOS Stream, Alma Linux, Rocky Linux, openSUSE и прочего) "до их замены на сертифицированные отечественные операционные системы". Я разбирал эти рекомендации.

5. ФСТЭК "Руководство по организации процесса управления уязвимостями в органе (организации)". Подробное описание этапов процесса, участников процесса и выполняемых ими операций. Я написал комментарии к проекту руководства "процесс не для человеков" и "место автоматического детектирования уязвимостей".

Заметил, что проект руководства по управлению уязвимостями, который был публично доступен на сайте ФСТЭК с 31 марта по 17 апреля для сбора отзывов, с сайта убрали

Заметил, что проект руководства по управлению уязвимостями, который был публично доступен на сайте ФСТЭК с 31 марта по 17 апреля для сбора отзывов, с сайта убрали. Видимо теперь уже до доработанного официального релиза. Поэтому ту публичную версию от 31 марта заливаю сюда. Чтобы было понятно к чему относятся мои комментарии про "процесс не для человеков" и "место автоматического детектирования уязвимостей". Кроме того, после официального релиза будет интересно посмотреть, что изменилось по сравнению с проектом.

Насчёт количества CVEшек в NVD и БДУ ФСТЭК

Насчёт количества CVEшек в NVD и БДУ ФСТЭК. Годы летят и обычно не задумываешься насколько быстро растет реестр NVD CVE. А ведь там действительно 212793 идентификаторов на текущий на текущий момент. 😱 Я вполне помню момент, когда их было 50к. 🙂

Что, реально так много? Не ошибка? Нет, похоже всё правильно:


$ for i in `seq 2002 2023`; do wget https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-$i.json.zip; done
$ zcat nvdcve-1.1-* | grep '"ID" : "CVE-[0-9]*-[0-9]*"' | sort | uniq | wc -l
212793

Для интереса посмотрел, а сколько ссылок на CVE есть в БДУ ФСТЭК:


$ wget --no-check-certificate https://bdu.fstec.ru/files/documents/vulxml.zip
$ unzip vulxml.zip
$ cat export/export.xml | egrep -o "CVE-[0-9]*-[0-9]*" | sed 's/\/identifier>//g' | sort | uniq | wc -l
37757

Можем видеть, что сильно меньше. О причинах судить не берусь, но точно можно сказать, что воспринимать БДУ просто как downstream NVD неправильно. Туда попадает, мягко говоря, не всё, что есть в NVD. В прочем, в NVD тоже есть не всё, что есть в БДУ.