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

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

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

Hel­lo every­one! On the last day of Sep­tem­ber, I decid­ed to record anoth­er ret­ro­spec­tive episode on how my Vul­ner­a­bil­i­ty Man­age­ment month went.

Edu­ca­tion
00:09 BMSTU online cyber secu­ri­ty course
00:33 Pos­i­tive Tech­nolo­gies online Vul­ner­a­bil­i­ty Man­age­ment course
00:52 Bahasa Indone­sia

Russ­ian Pod­casts
01:20 Прожектор по ИБ ("Infor­ma­tion Secu­ri­ty Spot­light") pod­cast
01:47 КиберДуршлаг ("Cyber Colan­der") by Pos­i­tive Tech­nolo­gies

Main Job
01:57 Good­bye Tin­koff

Patch Tues­day
02:54 Sep­tem­ber Microsoft Patch Tues­day
03:11 Remote Code Exe­cu­tion – Microsoft Edge/libwebp (CVE-2023–4863), Mem­o­ry Cor­rup­tion – Microsoft Edge (CVE-2023–4352)
04:11 Remote Code Exe­cu­tion – Win­dows Themes (CVE-2023–38146) "The­me­Bleed"
04:48 Infor­ma­tion Dis­clo­sure (NTLM relay attack) – Microsoft Word (CVE-2023–36761)
05:19 Ele­va­tion of Priv­i­lege – Microsoft Stream­ing Ser­vice Proxy (CVE-2023–36802)
05:36 Remote Code Exe­cu­tions — Microsoft Exchange (CVE-2023–36744, CVE-2023–36745, CVE-2023–36756)

Oth­er Vul­ner­a­bil­i­ties
06:54 Bitrix CMS RCE (BDU:2023–05857)
07:32 RHEL/CentOS 7 can’t be detect­ed, can’t be fixed vul­ner­a­bil­i­ty (CVE-2022–1012)
08:09 Qualys TOP 20 vul­ner­a­bil­i­ties

Vul­ner­a­bil­i­ty Man­age­ment Mar­ket
09:06 For­rester and GigaOm VM Mar­ket reports
09:49 R‑Vision VM

🎞 Video
🎞 Video2 (for Rus­sia)
📘 Blog­post

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак, вы решили начать разработку своего Vul­ner­a­bil­i­ty Man­age­ment решения. Часть 3. На чем можно срезать углы?

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

1. Весьма соблазнительно взять опенсурсный сканер и, несколько доработав его, начать продавать как коммерческий продукт или сервис. Например, взять OpenVAS/GVM, Nuclei, Nmap. Однако следует понимать, что вместе с наработками придется брать в нагрузку и немалое легаси. И возможно реализовать какую-то конкретную функциональность с нуля было бы проще, чем поддерживать форк проекта с историей. Кроме того за успешным опенсурсным сканером, как правило, стоит коммерческая компания, которая этот проект уже монетизирует и конкурентам не рада. Стоит ожидать, что вам будут вставлять палки в колеса, например через хитрое лицензирование (Nmap) или ограничение бесплатного публичного фида с детектами (OpenVAS/GVM). И тут уж как впишитесь.
2. Часто для того, чтобы по-быстрому добавить детектирование уязвимостей реализуют такую схему: детектирование CPE идентификатора установленного софта и поиск уязвимостей в базе NVD. Просто, быстро, универсально. Но далеко не всегда достоверно, т.к. ошибки могут быть и при детектировании CPE, и описании уязвимой конфигурации в NVD. Да и не всё всегда определяется версиями софта, свою роль могут играть патчи и их перекрытия. Продемонстрировать как такая схема работает можно на примере Nmap + Vul­ners plu­g­in. Nmap тут отвечает за детект CPE, а Vul­ners за поиск по NVD.
3. Отдельная большая тема это SCAP/OVAL. Если кратко, то это набор открытых спецификаций для описания уязвимостей/мисконфигураций и того как их по этому описанию детектировать. Есть много бесплатного публичного контента: репозиторий CIS, DISA STIGs, профили PCI DSS от Open­SCAP, Win­dows уязвимости в коненте от ФСТЭК/АЛТЭКС-СОФТ, вендорский контент для Ubun­tu, Debian, RHEL. Есть как минимум один опенсурсный SCAP/OVAL сканер, который все ещё развивается, это Open­SCAP от Red­Hat. Есть старые заброшенные проекты oval­di и joval­di. C открытыми SCAP/OVAL сканерами под Win­dows все традиционно тяжко, Open­SCAP в этом направлении шел, но не так давно под Win­dows его перестали поддерживать. Следует отметить, что продвигается эта тема в первую очередь американцами для контроля безопасности их государственной инфры (для военных и федеральных агентств в основном). Чуть менее чем все вакансии по SCAP/OVAL открываются в США и требуют американское гражданство и clear­ance, что намекает. 😉 Также они навязывают VM-вендорам поддерживать SCAP/OVAL, что те и делают, кто-то более формально, кто-то менее. В общем, есть соблазн в это дело крепко влезть, чтобы реюзнуть наработки. И есть как минимум одна suc­cess sto­ry у кого это получилось — Red­Check от АЛТЭКС-СОФТ. Также можно привести в пример индийскую компанию Sec­pod. Из минусов — спецификации там не особо простые и удобные, делать всё строго по ним достаточно тяжко, особенно реализовывать нестандартные проверки для нестандартных систем.

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