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

Подбил итоги сентября для англоязычного канала и блога

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

Подбил итоги сентября для англоязычного канала и блога. Сентябрь получился отличный! 😊 Много разнообразных активностей удалось реализовать и разрулить. А с учётом непубличного так и вообще удивительно как всё в итоге удачно сложилось. 🙂 По Patch Tuesday: обратите внимание, что libwebp CVE-2023-4863 теперь идёт с уровнем Urgent, т.к. на гитхабе выложили эксплоит.

---

Hello everyone! On the last day of September, I decided to record another retrospective episode on how my Vulnerability Management month went.

Education
00:09 BMSTU online cyber security course
00:33 Positive Technologies online Vulnerability Management course
00:52 Bahasa Indonesia

Russian Podcasts
01:20 Прожектор по ИБ ("Information Security Spotlight") podcast
01:47 КиберДуршлаг ("Cyber Colander") by Positive Technologies

Main Job
01:57 Goodbye Tinkoff

Patch Tuesday
02:54 September Microsoft Patch Tuesday
03:11 Remote Code Execution – Microsoft Edge/libwebp (CVE-2023-4863), Memory Corruption – Microsoft Edge (CVE-2023-4352)
04:11 Remote Code Execution – Windows Themes (CVE-2023-38146) "ThemeBleed"
04:48 Information Disclosure (NTLM relay attack) – Microsoft Word (CVE-2023-36761)
05:19 Elevation of Privilege – Microsoft Streaming Service Proxy (CVE-2023-36802)
05:36 Remote Code Executions - Microsoft Exchange (CVE-2023-36744, CVE-2023-36745, CVE-2023-36756)

Other Vulnerabilities
06:54 Bitrix CMS RCE (BDU:2023-05857)
07:32 RHEL/CentOS 7 can’t be detected, can’t be fixed vulnerability (CVE-2022-1012)
08:09 Qualys TOP 20 vulnerabilities

Vulnerability Management Market
09:06 Forrester and GigaOm VM Market reports
09:49 R-Vision VM

🎞 Video
🎞 Video2 (for Russia)
📘 Blogpost

По итогам выступления на Positive Customer Day

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

По итогам выступления на Positive Customer Day. Всё прошло вполне удачно. Спасибо большое коллегам из Positive Technologies за приглашение! Кажется это был мой первый доклад на "бумажную" тему. Хоть я, в основном, делал акценты на технические сложности при реализации методик, но всё равно. Оказалось, что у "бумажных" докладов своя специфика. Были вопросы в духе: почему регулятор написал документ так, а не иначе? Почему он что-то учёл, а что-то решил не учитывать? Зачем регулятор вообще выпустил тот или иной документ? Раньше я с таким не сталкивался и даже впал в лёгкий ступор. Можно, конечно, что-то фантазировать на эту тему, но такие вопросы явно не по адресу. 😅

В целом же, по итогам Q&A для себя сформулировал следующее:

1. В методику оценки критичности уязвимостей неплохо было бы добавить учёт использования уязвимости в реальных атаках (аналог CISA KEV) и вероятности появления эксплоита для неё (аналог EPSS)
2. В руководство по построению процесса управления уязвимостями было бы неплохо добавить:
2.1. Требования к актуальности данных об обнаруженных уязвимостях, например максимально допустимую периодичность сканирования. Не должно быть возможности сканировать раз в квартал и делать какие-то выводы на основе этого.
2.2. Требования к полноте покрытия активов. Не должно быть активов (хостов, софтов, сетевых устройств и т.д.), которые не покрываются средствами детектирования уязвимостей. Должен быть какой-то процесс подтверждения, что VM-решение умеет детектировать уязвимости для всех активов в организации. Если есть какой-то актив, для которого автоматическое детектирование уязвимостей не производится, нужно с этим что-то делать. Как минимум подсветить.
2.3. Требования к оценке качества детектирования уязвимостей. Ситуация, когда несколько средств детектирования анализируют один и тот же актив и выдают совершенно разные наборы уязвимостей ненормальная. Если так происходит, значит в каких-то решениях реализована неправильная логика и такие решения нельзя использовать в процессе управления уязвимостями ("мусор на входе - мусор на выходе"). Следует ли из этого, что должен быть процесс сертификации средств детектирования уязвимостей, такой как для PCI ASV или SCAP сканеров? Возможно.

Ещё в выступлении я, среди прочего, позволил себе предположить, что подход Positive Technologies к VM-у (который я лично всячески поддерживаю), предполагающий процесс регулярного безусловного патчинга инфраструктуры не особенно сочетается с руководством ФСТЭК по построению процесса управления уязвимостями, т.к. это руководство требует тестирования обновлений для open-source и нероссийского софта по методике ФСТЭК перед установкой. Т.е. процесс регулярного безусловного патчинга может и быть, но кажется момент с тестированием обновлений должен быть определен: тестируем/не тестируем, если тестируем, то чьими силами и в каком объёме.

К слову о том, чем я ещё занимался на праздниках

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

К слову о том, чем я ещё занимался на праздниках

К слову о том, чем я ещё занимался на праздниках. Поковырял официальный Debian OVAL контент и сделал про это эпизод. Из неочевидного:

1. Дефинишены заводятся не по бюллетеням, я по CVE+пакет
2. Нет ссылок на DSA и DLA бюллетени (upd. Хе, тут я погорячился, на самом деле для некоторых дефинишенов DSA идентификаторы есть, я плохо смотрел)
3. Фактически никак не учитывается архитектура при детекте

В общем, занимательно, но к авторам этого контента есть вопросики. 🙂

Кстати узнал, что для RedOS есть официальный OVAL-контент (XML, 1.1 мб)

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

Кстати узнал, что для RedOS есть официальный OVAL-контент (XML, 1.1 мб)

Кстати узнал, что для RedOS есть официальный OVAL-контент (XML, 1.1 мб). И даже есть статья на русском как его использовать для детектирования уязвимостей на хостах при помощи OpenSCAP. VM-щикам сканеристам теперь можно удобно обновлять свои базы знаний, забирая данные из этой публично доступной XML-ки в стандартном формате. А не возиться с черти как оформленными бюллетеньками, которые ещё и не факт, что вообще есть. Нужно ли говорить, что в моём личном рейтинге отечественных операционных систем RedOS теперь взлетела в самый-самый топ. 😍 Молодцы 👍

Чем ответит купечество, т.е. остальные вендоры российских Linux-ов? 🙂

Итак, вы решили начать разработку своего Vulnerability Management решения

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

Итак, вы решили начать разработку своего Vulnerability Management решения. Часть 3. На чем можно срезать углы?

Подводные камни подсветили, специализаций коснулись. В этой завершающей части посмотрим как можно быстро слепить VM-решение из того, что есть в паблике:

1. Весьма соблазнительно взять опенсурсный сканер и, несколько доработав его, начать продавать как коммерческий продукт или сервис. Например, взять OpenVAS/GVM, Nuclei, Nmap. Однако следует понимать, что вместе с наработками придется брать в нагрузку и немалое легаси. И возможно реализовать какую-то конкретную функциональность с нуля было бы проще, чем поддерживать форк проекта с историей. Кроме того за успешным опенсурсным сканером, как правило, стоит коммерческая компания, которая этот проект уже монетизирует и конкурентам не рада. Стоит ожидать, что вам будут вставлять палки в колеса, например через хитрое лицензирование (Nmap) или ограничение бесплатного публичного фида с детектами (OpenVAS/GVM). И тут уж как впишитесь.
2. Часто для того, чтобы по-быстрому добавить детектирование уязвимостей реализуют такую схему: детектирование CPE идентификатора установленного софта и поиск уязвимостей в базе NVD. Просто, быстро, универсально. Но далеко не всегда достоверно, т.к. ошибки могут быть и при детектировании CPE, и описании уязвимой конфигурации в NVD. Да и не всё всегда определяется версиями софта, свою роль могут играть патчи и их перекрытия. Продемонстрировать как такая схема работает можно на примере Nmap + Vulners plugin. Nmap тут отвечает за детект CPE, а Vulners за поиск по NVD.
3. Отдельная большая тема это SCAP/OVAL. Если кратко, то это набор открытых спецификаций для описания уязвимостей/мисконфигураций и того как их по этому описанию детектировать. Есть много бесплатного публичного контента: репозиторий CIS, DISA STIGs, профили PCI DSS от OpenSCAP, Windows уязвимости в коненте от ФСТЭК/АЛТЭКС-СОФТ, вендорский контент для Ubuntu, Debian, RHEL. Есть как минимум один опенсурсный SCAP/OVAL сканер, который все ещё развивается, это OpenSCAP от RedHat. Есть старые заброшенные проекты ovaldi и jovaldi. C открытыми SCAP/OVAL сканерами под Windows все традиционно тяжко, OpenSCAP в этом направлении шел, но не так давно под Windows его перестали поддерживать. Следует отметить, что продвигается эта тема в первую очередь американцами для контроля безопасности их государственной инфры (для военных и федеральных агентств в основном). Чуть менее чем все вакансии по SCAP/OVAL открываются в США и требуют американское гражданство и clearance, что намекает. 😉 Также они навязывают VM-вендорам поддерживать SCAP/OVAL, что те и делают, кто-то более формально, кто-то менее. В общем, есть соблазн в это дело крепко влезть, чтобы реюзнуть наработки. И есть как минимум одна success story у кого это получилось - RedCheck от АЛТЭКС-СОФТ. Также можно привести в пример индийскую компанию Secpod. Из минусов - спецификации там не особо простые и удобные, делать всё строго по ним достаточно тяжко, особенно реализовывать нестандартные проверки для нестандартных систем.

На этом мини-цикл про разработку VM я заканчиваю, но тему сканероделания конечно не оставляю. Дальше как раз планирую в очередной раз погружаться в SCAP/OVAL, следующий плановый эпизод будет про детектирование уязвимостей с помощью OpenSCAP.