Архив рубрики: Темы

Про сканер уязвимостей в Yandex Cloud

Про сканер уязвимостей в Yandex Cloud. На днях были новости, что Yandex открыл доступ к своему сканеру уязвимостей. Из этих новостей было не очень понятно что за сканер, для чего сканер. Но я нашел первоисточник - блогопост на сайте Яндекс Клауда.

1. Речь о сканере для Docker-образов, интегрированный в сервис Yandex Container Registry. Это аналог Aqua Trivy, Clair, Falco, Docker scan. Ну и моего Scanvus-а. 🙂 И видимо имеется ввиду Сканер уязвимостей описанный в документации, поддерживающий Alpine, CentOS, Debian, Redhat, Ubuntu в качестве ОС, на которых могут быть собраны пользовательские Docker-образы.

2. В чем преимущество: "Чтобы использовать сканер уязвимостей Yandex Cloud, не требуется выделять дополнительную инфраструктуру, обслуживать её, заниматься разворачиванием и поддержкой продукта или глобально менять процесс выкладки кода. "

3. Описание сканера частично понятно, детект по пакетам: "по результатам сканирования образа пользователь получает отчёт об уязвимостях, обнаруженных в конкретных пакетах ОС, и о версиях этих пакетов с исправлениями, если такие имеются". А то, что понимается под "сканер уязвимостей с использованием статического анализа" - загадочно.

4. Уровни сканирования: реестра целиком и выбранных репозиториев. Сканирование отдельных образов и фильтрации по тегам пока нет, но обещают.

5. Сколько стоит: "Первые шесть первичных и шесть последующих сканирований бесплатны. Начиная с седьмого раза нужно будет платить: за каждое первичное — 13,2 рубля, а за последующее — 7,2 рубля."

Ещё раз про EPSS Probability и EPSS Percentile

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

Ещё раз про EPSS Probability и EPSS Percentile. В одной соцсеточке для профессионального общения от компании Microsoft меня увещевают отказаться от ереси и все-таки использовать EPSS Probability в Vulristics вместо EPSS Percentile. 🙂 Кажется имеет смысл продолжить тему.

1. Про разницу между Probability и Percentile, как их понимать и интерпретировать, есть подробная статья на официальном сайте. Вопрос: можно ли как-то получить из EPSS уровни критичности а-ля CVSS Base Score. Ответ: нет, нельзя. "По этим причинам EPSS в настоящее время не группирует результаты EPSS с использованием ярлыков" ("For these reasons, EPSS does not currently bin EPSS scores using labels"). В своём праве.

2. То, что они генерят в виде EPSS Probability, "вероятности эксплуатации", это просто очень маленькие цифири из нейронки, которые непонятно как сравнивать адекватно. Они даже в тех примерах, которые я рассматривал, маленькие. EPSS-ники сами об этом пишут в статье "Например, как пользователи должны интерпретировать общую важность (overall importance) уязвимости с вероятностью 0,212? Или, по-другому, как мы должны думать о сравнении относительной разницы в угрозе между вероятностью 0,115 и 0,087? Да, одна больше другой, но насколько больше? Насколько велика разница в угрозе первой уязвимости по сравнению со второй?" Для прошлого Patch Tuesday EPSS Probability для всех уязвимостей, была между 0 и 0.2 (0-20%). Даже для уязвимостей с отмеченной эксплуатацией в CISA KEV! Это с каким же весом мне надо брать эти значения, чтобы они хоть как-то влияли на итоговый скор? 🙂

3. Ну да, EPSS Percentile это результат ранжирования уязвимостей по EPSS Probability, величина искусственная и зависит от общего числа CVE. И она меняется со временем, так же как и EPSS Probability. Ну так и в чем проблема? EPSS Percentile это тоже какая-то искусственная величина из нейронки полученная. По EPSS Percentile хотя бы видно как эта нейронка оценивает конкретную уязвимость относительно всех остальных. То, что нам собственно и надо. 😉 И тут более-менее понятно, есть 0.8-1, то критично, а если 0-0.2 это фигня какая-то. Ну, в идеале. Потому что на практике, как я уже подсвечивал, бывают странности.

Добавил учёт EPSS в Vulristics

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

Добавил учёт EPSS в Vulristics. EPSS стал ещё одним источником данных, т.е. команда для анализа набора CVE будет выглядеть так:

$ python3 vulristics.py --report-type "cve_list" --cve-project-name "New Project" --cve-list-path "analyze_cve_list.txt" --cve-comments-path "analyze_cve_comments.txt" --cve-data-sources "ms,nvd,epss,vulners,attackerkb" --rewrite-flag "True"

Добавление нового источника задача несложная. Сделал по аналогии с NVD. Однако возник вопрос: какое именно значение EPSS использовать. Было 2 варианта:

1. Probability - вероятность наблюдения эксплуатации уязвимости в течение следующих 30 дней ("probability of observing exploitation activity in the next 30 days").

2. Percentile - значение показывающее насколько вероятность наблюдения эксплуатации данной CVE уязвимости больше чем для всех других CVE уязвимостей. Например, вероятность EPSS, равная всего 0,10 (10%), находится примерно на уровне 88-го процентиля, что означает, что 88% всех CVE имеют более низкую оценку ("For example, an EPSS probability of just 0.10 (10%) rests at about the 88th percentile — meaning that 88% of all CVEs are scored lower").

В итоге опытным путем пришел к тому, что Probability слишком малы, а также мало различаются, поэтому лучше использовать Percentile.

Я перегенерил отчет для апрельского MS Patch Tuesday.

1. Старый отчет без EPSS
2. Новый отчет с EPSS

Выглядит довольно неплохо, но со странностями. Так наиболее критичная Elevation of Privilege - Windows Common Log File System Driver (CVE-2023-28252), которая присутствует в CISA KEV почему-то имеет очень низкий EPSS. 🤷‍♂️ Поэтому результат нейронки это, конечно, хорошо, но здравый смысл терять не нужно. 😉

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

1 комментарий

Насчёт количества 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 тоже есть не всё, что есть в БДУ.

Мама, я в телевизоре! Вернее в телеграмм-канале Алексея Лукацкого

1 комментарий

Мама, я в телевизоре! Вернее в телеграмм-канале Алексея Лукацкого. И не так важно, что это коммент про неудобочитаемость аббревиатур для классов решений из моей карты отечественных средств управления уязвимостями. Сам факт упоминания главным ИБ-блогером страны (17к+ подписчиков) и просто человеком-легендой считаю большой честью и успехом. Спасибо! 🙂

Что касается аббревиатур, то я специально хотел, чтобы на русском звучало основательно и в лучших традициях отечественного ИБ-нейминга, как БнД УБИ ФАУ «ГНИИИ ПТЗИ ФСТЭК России». Если получившиеся СУУ, СДУИ, СДУСП, СДУП, СДУК, САУ, СИУ какие-то такие ассоциации навевают, значит эффект достигнут. 😉

Плюс, всё изначально задумывалось с учетом перевода на английский:

Vulnerability Management Tools (VMT)
1. Vulnerability Detection Tools for Infrastructure (VDTI)
2. Vulnerability Detection Tools for Network Perimeter (VDTNP)
3. Vulnerability Detection Tools for Applications (VDTA)
4. Vulnerability Detection Tools for Code (VDTC)
5. Vulnerability Analysis Tools (VAT)
6. Vulnerability Remediation Tools (VRT)

И в таком виде уже смотрится как-то более привычно. 🙂

О месте автоматического детектирования уязвимостей (сканирования) в проекте руководства ФСТЭК по управлению уязвимостями

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

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

Этап мониторинга уязвимостей и оценки их применимости

• Принятие решений на получение дополнительной информации
• Постановка задачи на сканирование объектов
• Сканирование объектов

Этап контроля устранения уязвимостей

• Принятие решения о способе контроля
• Проверка объектов на наличие уязвимостей

Это упоминания в том смысле, что разовые задачи на сканирование должны быть кем-то в рамках процесса поставлены и кем-то выполнены. Однако там нет конкретных требований, которые могли бы обеспечить полноту по активам, актуальность данных и качество детектирования:

1. Нет требований, что все активы в организации должны быть покрыты средствами анализа защищенности.
2. Нет требований, что в любой момент времени необходимо иметь актуальные данные о состоянии инфраструктуры с точки зрения имеющихся уязвимостей.
3. Нет требований к средствам анализа защищённости, как они должны работать и какие возможности по детектированию уязвимостей должны иметь.
4. Не предусмотрено процедуры оценки полноты и качества детектирования уязвимостей.

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

И, говоря об оценке качества детектирования, раз уж есть ScanOVAL (для российских Linux-ов и Windows), то почему бы не зафиксировать его статус в качестве эталонного средства анализа защищенности и не обязать периодически проводить сверку результатов детектирования ScanOVAL c результатами полученными от средств анализа защищенности, используемых в организации? Как минимум это привлечет внимание к проблеме качества детектирования уязвимостей (как соответствию эталону, так и улучшению эталона), которая сейчас, к сожалению практически не обсуждается.

В комментах в ВК (а туда всё дублируется и вы можете там комментить) мне написали, что в последнем посте слишком много аббревиатур и непонятно даже в чём весь цимес

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

В комментах в ВК (а туда всё дублируется и вы можете там комментить) мне написали, что в последнем посте слишком много аббревиатур и непонятно даже в чём весь цимес. Видимо я слишком усушил текст, чтобы в лимиты поста с картинкой уложиться, сорри. 😅 Дело вот в чем.

1. Есть уязвимость в архиваторе WinRAR, для которой Positive Technologies предварительно получили CVE идентификатор.

2. После того как уязвимость была исправлена, Mitre Corporation (они держат реестр CVE идентификаторов и являются апстримом для National Vulnerability Database) по какой-то причине начали использовать этот ранее выданный CVE идентификатор для какой-то другой уязвимости, которая к WinRAR никак не относится.

3. Можно подумать, что случилась какая-то ошибка и Mitre завели эту уязвимость WinRAR под другим CVE идентификатором. Но нет, других уязвимостей WinRAR с похожим описанием за 2021 год и позже не наблюдается. Просто забили.

Почему так вышло? Кто его знает, Mitre нам не расскажут. Можно предположить такую логику Mitre: "вы, Positive Technologies, под санкциями, мы от вас больше уязвимости принимать не будем". В итоге сложилась ситуация, когда один и тот же CVE идентификатор CVE-2021-35052 используется для ссылки на две совершенно разные уязвимости. Коллизия. 🤷‍♂️

Разумеется, это очень странное и контрпродуктивное поведение со стороны Mitre. Но дело не только в них. Было несколько похожих эпизодов с западными IT-вендорами, когда PT на сообщение об уязвимости либо не отвечали, либо в acknowledgement не ставили. А, например, в случае с Citrix сначала добавили acknowledgement, потом тихонько убрали, а после публичного обсуждения вернули назад. Насколько я понимаю, такое было не только с PT, но и с Digital Security, и с другими исследовательскими компаниями под американскими санкциями.

В общем, здорово, что у нас есть национальная база уязвимостей в виде БДУ ФСТЭК, где есть, кроме прочего, и уязвимости для которых Mitre отказались по каким-то причинам идентификаторы выдавать.

Александр В. Леонов

Управление Уязвимостями и прочее